Deployment · CryptoRail

Three shapes

Pick the one that fits your control requirements.

The usual path is a pilot sandbox first, then CryptoRail in your own infrastructure. Running it for you is offered for pilots today and for production after the external security audit.

Self-hosted

Runs in your infrastructure, as a container image over your PostgreSQL, with schema migrations applied by an explicit command.

You operate it, your keys stay wherever you keep them, and your data never leaves your infrastructure.

Run for you

Run for you in production without ever holding a key of its own: signing stays on your side or in your own cloud account. Available for pilots

The hosted profile refuses to start if it is given a key of its own, listing every reason.

Pilot sandbox

A pilot environment stood up in minutes with nothing installed on your side.

A sandbox says it is one: in its logs, on its health endpoint and on every screen built over it. It is never supported for value.

Side by side

Who runs it, and where the keys are.

The profile is checked in every process at startup; a deployment that breaks its profile's promise does not start.

Profile	Who operates it	Where the keys are	For value
Self-hosted	You	Your HSM, your cloud KMS or your own signer	Yes
Run for you	CryptoRail	On your side, or in your own cloud account	After the audit
Pilot sandbox	CryptoRail	In the sandbox, test keys only	Never

Inside your infrastructure

A library or a service, one process or several.

Small teams embed CryptoRail in their own application. Larger ones run it as a service and split it into an API, workers and an indexer, scaled separately and connected only through the database. Nodes, signers, storage and event publishers are all replaceable.

Embedded as a library in your Node.js application, or run as a service with an HTTP API described in OpenAPI and generated SDKs.
One process, or separate API, worker, signing gate and indexer processes sharing only the database, each with a database role limited to what it needs.
Several workers on the same database without sending anything twice.
Works with your own nodes or a provider's, through standard Ethereum JSON-RPC over plain HTTP.
Every external concern is a documented port: replace a signer, a store or a publisher with your own, and prove it with the contract tests.
Authentication with mutual TLS or OIDC tokens, beside API keys. On request

flowchart TD
    Y[Your systems] -->|HTTP API or SDK| A[API]
    A --> DB[(Your PostgreSQL)]
    W[Workers] --> DB
    IX[Indexer] --> DB
    W --> S[Your signer, HSM or cloud KMS]
    W --> N[Your nodes or a provider]
    IX --> N
    IX -->|signed webhooks| Y