Superzero gives an application its database, hosting, authentication and mobile push from a single declarative file. No dashboard steps, no console clicking, no second vendor. An agent writes one file and runs one command.
Writing the code stopped being the bottleneck. Connecting the infrastructure did — and that work lives in dashboards, which is exactly where agents are weakest.
SMS authentication and push notifications are the real hole. Outside Firebase, essentially no modern developer platform has either. Push in particular costs almost nothing to run — APNs and FCM are free — and no competitor offers it.
The schema is strict: unknown keys are rejected rather than silently
ignored, so a typo fails loudly instead of quietly doing nothing. Secrets are
$SECRET references — never values in the file.
import { defineConfig } from '@superzero/config'
export default defineConfig({
name: 'shopping-app',
region: 'ap-northeast-1',
database: { extensions: ['pgvector'] },
compute: {
framework: 'auto', // detected by Nixpacks
envFrom: ['database', 'auth'],
idleTimeout: '15m', // scale to zero
},
auth: {
providers: ['email', 'google'],
sms: { enabled: true, allowedCountries: ['JP'] },
},
push: {
ios: { bundleId: 'com.example.shop', keyId: '$SECRET', teamId: '$SECRET' },
android: { packageName: 'com.example.shop' },
},
})
$ superzero plan + database:default create Neon project (postgres, pgvector) + compute:default build and start container + auth:default enable email, google, sms(JP) $ superzero apply ok database:default ready 4.2s ok compute:default ready 38.1s ok auth:default ready 0.9s https://shopping-app.superzero.dev
No prompts, no TTY assumptions, no browser step. The same operations are
exposed as MCP tools — superzero_plan, superzero_apply,
superzero_verify, superzero_status — so an agent uses the
product without shelling out at all.
A human reads a stack trace and infers the next move. An agent needs that
move as data. Every failure returns a stable code and a suggestedFix naming
the command to run and what to change.
This is the discipline the whole product is organised around: if a failure cannot say how to recover, it is not finished.
{
"code": "COMPUTE_CONTAINER_EXITED",
"message": "The container started but exited immediately (id: c2a4f9b2e1de).",
"suggestedFix": {
"command": "superzero logs",
"description": "Read the container logs to see why the process exited.
Set compute.startCommand in superzero.config.ts if the
framework was detected incorrectly."
}
}
This is a P0 prototype. It is not open for sign-up, and there is no pricing yet. What follows is what has actually been run end to end, not a roadmap.
| Capability | State | Verified against |
|---|---|---|
| Provisioning engine | working | plan / apply / destroy, idempotent re-apply, partial-failure recovery |
| Postgres | working | Real Neon projects created and deleted through the API |
| Container hosting | working | Nixpacks build, Docker Engine API, Caddy routing, scale-to-zero activator |
| Secret storage | working | Envelope encryption against real AWS KMS |
| Auth (email, OAuth) | working | Argon2id, JWT, PKCE with state and nonce checks |
| CLI and MCP | working | Both drive a full apply against the control plane |
| SMS OTP | blocked | Implemented with five abuse-prevention layers; awaiting carrier account approval |
| Push (APNs, FCM) | blocked | Implemented; awaiting provider credentials |
Machine-readable descriptions of this project, kept in step with the source:
| /llms.txt | Short index. What this is, and where the detail lives. |
| /llms-full.txt | Full reference: config schema, commands, MCP tools, error codes. |