Your application. Its infrastructure. The next change.
Zenith is a local-first deployment and operations platform that puts the plan in your hands.
Bring your own cloud. Keep your model.
Review the queue and both bindings before the change runs. The next revision starts with your decision.
Inspect a resource to read its bindings.
Standard queue · SQS-shaped · nano estimate tier. Buffers background work between the API and worker.
atlas-api → atlas-jobsqueue_publishatlas-worker → atlas-jobsqueue_consumeStatic estimate: two small services, one replica each; one nano queue. Synthetic configuration, not a billing quote.
The binding makes a queue available to the worker. Your application still needs to publish and consume jobs correctly, including retries and duplicate handling.
Nothing runs until you review this plan and choose Run simulation.
Move between the map, the source, the API and Navigator. Each surface reads the same Atlas revision you selected above.
queue_publishqueue_consumeThe API publishes to atlas-jobs. The worker consumes from it. Each line is an explicit capability in the manifest.
Services, resources and bindings are declared together. The Source view edits this same structure through a typed action.
Read-only demonstration. Image references use example.invalid; they are not deployable application images.
// SYNTHETIC · atlas · revision 09
// Canonical manifest · illustrative image references
{
"version": 1,
"services": [
{
"id": "atlas-api",
"name": "atlas-api",
"kind": "web",
"source": {
"type": "image",
"image": "example.invalid/atlas-api:demo"
},
"size": "small",
"replicas": 1,
"port": 8080,
"env": [],
"ownership": "managed"
},
{
"id": "atlas-worker",
"name": "atlas-worker",
"kind": "worker",
"source": {
"type": "image",
"image": "example.invalid/atlas-worker:demo"
},
"size": "small",
"replicas": 1,
"env": [],
"ownership": "managed"
}
],
"resources": [
{
"id": "atlas-jobs",
"name": "atlas-jobs",
"kind": "queue",
"config": {},
"size": "nano",
"ownership": "managed"
}
],
"routes": [],
"bindings": [
{
"id": "api-publishes-jobs",
"from": "atlas-api",
"to": "atlas-jobs",
"capability": "queue_publish",
"note": "API publishes background jobs."
},
{
"id": "worker-consumes-jobs",
"from": "atlas-worker",
"to": "atlas-jobs",
"capability": "queue_consume",
"note": "Worker consumes background jobs."
}
]
}This example plans an update to the same manifest. The product separates planning and execution with explicit action modes.
Illustrative request using the existing endpoint schema. No request is sent; sim-atlas is a fixture identifier.
// SYNTHETIC · revision 09
// Request example only. No request is sent.
POST /api/actions/project.updateManifest
Content-Type: application/json
{
"mode": "plan",
"scope": {
"projectId": "sim-atlas"
},
"input": {
"projectId": "sim-atlas",
"manifest": {
"version": 1,
"services": [
{
"id": "atlas-api",
"name": "atlas-api",
"kind": "web",
"source": {
"type": "image",
"image": "example.invalid/atlas-api:demo"
},
"size": "small",
"replicas": 1,
"port": 8080,
"env": [],
"ownership": "managed"
},
{
"id": "atlas-worker",
"name": "atlas-worker",
"kind": "worker",
"source": {
"type": "image",
"image": "example.invalid/atlas-worker:demo"
},
"size": "small",
"replicas": 1,
"env": [],
"ownership": "managed"
}
],
"resources": [
{
"id": "atlas-jobs",
"name": "atlas-jobs",
"kind": "queue",
"config": {},
"size": "nano",
"ownership": "managed"
}
],
"routes": [],
"bindings": [
{
"id": "api-publishes-jobs",
"from": "atlas-api",
"to": "atlas-jobs",
"capability": "queue_publish",
"note": "API publishes background jobs."
},
{
"id": "worker-consumes-jobs",
"from": "atlas-worker",
"to": "atlas-jobs",
"capability": "queue_consume",
"note": "Worker consumes background jobs."
}
]
}
}
}Navigator proposes typed actions against the same model. Autonomy settings and environment policies determine which actions require your approval.
This conversation is scripted. The interactive simulation above always requires your explicit approval.
Add a queue between the API and the worker.
Revision 09 contains atlas-jobs and two bindings: atlas-api can publish; atlas-worker can consume.
Review the worker’s retry behavior before applying. A binding provides configuration; the application implements the job handling.
Review the plan above, then explicitly choose Run simulation.
Navigator turns what you want into typed, reviewable actions. Gimbal is your companion along the way: a visible expression of what’s happening, and when it needs you.
Both use the same model you just explored. The same resources. The same approval boundaries. Every action leaves a record.
Explore the five autonomy levels. Deployment approval policies and budgets still apply.
Executes each step, but only after you approve it.
Policy explanations · no workspace setting is changedPreparing a typed plan.
Holding for your decision.
Running an approved action.
Authoritative, non-simulated provider evidence confirms the result.
A problem needs attention.
Ready, plan complete, simulation complete, or cancelled.
A simulation or completed plan is not a verified deployment. State always comes with a label and an icon.
Choose a starting point for the work you can do today. Your connection determines what can run.
Simulated deployment and operations. No infrastructure is provisioned.
Simulated cloud. Deploys run end-to-end in seconds with real timings and logs, but nothing is provisioned anywhere.
Supported S3 buckets and SQS queues with Docker + LocalStack. Application services, routes and other emulated behavior remain simulated.
Real S3 buckets and SQS queues against a reachable LocalStack endpoint. Application services, routes and other emulated behavior remain labeled simulations. Requires Docker + LocalStack running.
Real Terraform export. No in-app AWS apply, account reads or live account verification.
Preview: Zenith.ai plans your system as ECS/Fargate and exports real, runnable Terraform. It does not apply changes to your account yet.
Export the typed manifest, real Terraform, and an operations README. Continue with your own tooling, in your own environment.
Read the local setup guide (opens in a new tab)Start with an editable blueprint.
Make the next decision with the whole system in view.