Infrastructure overview

This page gives a high-level view of how Alphscan is built and run — for regular users and integrators. Operational and deployment details are not covered here.

​

Stack overview

Alphscan runs on AWS and uses:

• API — HTTP API (API Gateway v2) and Lambdas that serve the REST endpoints (tokens, chains, normalized events, system, etc.). The public API you call is this layer.
• Database — PostgreSQL (RDS) stores normalized events, API keys, tokens, address labels, chains, and other indexed data. The API and indexers read/write this database.
• Storage — S3 is used for media and static assets (e.g. token list JSON). Some token and config data is served from S3 when available.
• Cache — Redis (or similar) can be used by the indexer for rate limiting or deduplication.

The SDK and API reference tabs document how to call the API; the sections below explain where the data comes from.

​

Indexer

The indexer is a long-running process that connects to the Alephium blockchain (and any sidechains or config you use). It:

• Follows blocks and transactions.
• Extracts and normalizes events (e.g. contract calls, transfers) into a common schema.
• Writes normalized events and related data into PostgreSQL.

So when you call GET /transaction//normalized/events, the API reads from tables that the indexer has filled. The indexer can also backfill by address, token, or transaction when needed.

​

Data ingestion

A data ingestion service (or scripts) handles:

• Token list — Fetching or building the token list and syncing it to the database and/or S3 (e.g. for GET /token/all).
• Address labels — Seeding or updating label mappings and metadata for addresses.
• Other reference data — Any static or slowly changing data that the API or indexer depends on.

This keeps token metadata, labels, and similar data up to date without blocking the main indexer.

​

Job processor (reindexer)

A job processor (reindexer) runs background jobs: for example, reindexing a range of blocks or processing user-triggered tasks. Jobs are stored in the database; the processor picks them up and updates the same PostgreSQL data the API reads. Admin endpoints like GET /system/jobs list these jobs.

​

Status and uptime

We use a public status page so you can see the current state of the API and related services: Alphscan / Alephium status — status.babypooltool.com Check it for incidents, scheduled maintenance, and uptime. If the API is slow or returning errors, the status page is the first place to look.

​

Hosting (high level)

• API and Lambdas — Run on AWS (API Gateway + Lambda). The public base URL (e.g. https://api.alphscan.io) is fronted by a custom domain with SSL; traffic is routed to API Gateway and then to the appropriate Lambda.
• Database — PostgreSQL is hosted on AWS RDS. Read replicas can be used for the API to spread read load.
• Stages — We use stages (e.g. dev, prod) so production and development use separate API stages and, when desired, separate databases or resources.

For exact regions and deployment steps, refer to the project’s internal ops or deployment docs. For using the API, the API reference and Quickstart are the right entry points.