[ AxiomCore · Documentation ]
Build a backend
How an Acore backend turns typed declarations into a public contract, a private execution plan and a running HTTP service.
An AxiomCore backend is an HTTP service described by an Acore contract. This section shows how to declare a backend in Acore, run it locally, protect it, connect providers and package it for a deployment target. Both paths below produce a contract that clients, tests and Inspector can read.
| Start from | First guide | What stays yours |
|---|---|---|
| FastAPI | FastAPI | The Python application and its business logic |
| Go | Go | The Go application and its router |
| Acore | Build your first API | Authored models, actions, policies and deployment choices |
| A database-backed app | Run your first app | The database contract and typed storage mappings |
What a backend is made of
| File | Created by | Read by |
|---|---|---|
.acore source and AxiomDeps.toml with type = "backend" | You | Compiler and editor |
backend.axiom, the public contract | axiom build | Clients, tests, Inspector and Axiom Cloud |
backend.server.json, the private execution plan | axiom build, when the source declares server behavior | The server runtime only |
deployment.json, the private deployment | axiom server deployment, then your review | The server runtime only |
The public contract describes endpoints, models and client policies. The private plan holds actions, guards, resources and server policies, which clients never receive. The deployment names environment variables and grants, never secret values.
A request through an Acore backend
Diagram source
flowchart LR
A[Client] --> B[Transport or framework adapter]
B --> C[Limits and input validation]
C --> D[Identity]
D --> E[Guards and server policies]
E --> F[Action]
F --> G[Effect gate]
G --> H[Storage or provider]
H --> I[Output validation]
I --> J[Response]The transport applies size limits and validates the request against the contract. The server verifies the caller, then enforces the action's mandatory guards and the server policies (rate limits, idempotency, timeouts). The action runs as managed Acore code, a verified WebAssembly sandbox or registered native code. Each storage or provider call passes an effect gate that checks the declared operation and the deployment's grant. Output is validated before the response is sent. Execution plan gives the exact stage order.
Contract lifecycle
Diagram source
flowchart LR
A[Write .acore source] --> B[axiom check]
B --> C[axiom build]
C --> D[Contract and private plan]
D --> E[Inspect, test and diff]
E --> F[Review deployment.json]
F --> G[Run locally]
G --> H[Package for a target]
H --> I[Verify and release]- Write the source and validate it with
axiom check. - Build with
axiom build main.acore --out backend.axiom. This writes the contract and, beside it,backend.server.json. - Review with
axiom inspect,axiom server inspect,axiom test,axiom diff,axiom security checkandaxiom domain validate. Inspection reads artifacts; it does not run the backend. - Scaffold
deployment.jsonwithaxiom server deployment, then review its providers, authentication and grants. - Run the real service with
axiom runoraxiom serve, or choose an explicit mock. Add persistence with storage mappings. - Package for a deployment target, verify the bundle, and release. A Cloud contract release is immutable; publish a new version instead of overwriting one.
A built contract does not start or deploy a service.
Status
| Capability | Status |
|---|---|
| Backend contracts: check, build, inspect, semantic diff | Alpha |
| Managed actions, typed failures and local real serving | Experimental |
| SQLite and PostgreSQL storage mappings | Experimental |
| Deployment targets | Per target; see Deployment targets |
| FastAPI extraction / Go extraction | Available / Alpha; see Use your existing stack |
| HTTP adapters for FastAPI and Go Chi handlers | Experimental |
See Support and availability for the full matrix.
In this section
Backend declarations
Models, endpoints, actions, failures and storage.
Run a backend locally
Real serving, reload and mocks.
Identity and policies
Authentication, guards and admission.
Events, jobs and webhooks
Durable asynchronous work.
Integrations and transports
Caches, outbound HTTP, uploads, streams.
Secrets at runtime
Purpose-bound credentials.
Deployment targets
Where a backend can run.
Release a backend
Package, verify and roll back.
Execution plan
The private plan reference.
Next steps
Domain and security models
Add optional entities, relationships, invariants, projections and security policy to a backend contract, compiled into signed manifests.
Backend declarations
Reference for the Acore declarations that define backend models, entities, endpoints, actions, typed failures, storage mappings and route groups.