Passkeys and 2FA
Both are the platform's problem. Turn them on for everyone without touching an app.
Illustration: a coding agent is asked to build an on-call tracker with sign-in. It reads
the Astrodock contract, writes the app, runs astrodock apply and
astrodock deploy:watch, and the deploy succeeds. The finished app then
appears at its own address, first asking the visitor to sign in and then showing who is
currently on call.
Self-hosted app platform · open source
The hard part was never the app.
Your agent can write a working tool before lunch. Giving it a database, a domain, HTTPS and real user accounts is what eats the rest of the week. Astrodock is one install that removes all of it, then hands your agent the keys.
One command, one machine, ten minutes.
Sign-in you don't write
Your app never sees a password.
Send people to Astrodock to sign in and they come back with a one-time code your server trades for their identity. Accounts, passkeys and two-factor come with the platform instead of with your code, so a tool you threw together in an afternoon gets login you would be happy to put in front of customers.
One session, every app
Sign in once and you're signed in to everything you have access to.
Access per app
Grant someone the rota tool and not the invoicing one. They only see what's theirs.
Built to be handed over
Your agent already knows how to use it.
Astrodock ships a specification you can hand over. Point Claude Code or Cursor at
AGENTS.md and it has what it needs: the manifest schema, the
environment it will be handed, and a deploy command that streams until it can say
succeeded or failed, so your agent knows the outcome instead of
guessing at it.
It gets its own scoped key, too. It can ship apps and set secrets. It cannot touch your users.
The whole agent story →## 2. App layout contract app/ frontend, builds to app/dist/ server/ Express, entry server/server.js ### Hard rules for the server 1. Bind ASTRODOCK_PORT 2. Namespace routes under /api 3. GET /health → 200 4. Read config from injected env. Never hardcode. Never commit secrets.
What every app gets
Four vendors' worth of plumbing.
Declared in one file, provisioned on deploy, and yours to swap for a managed service the day you outgrow it.
Sign-in
Accounts, passkeys and two-factor, without a password reaching your code.
How sign-in works →Databases & storage
Its own Postgres and its own bucket. Or point it at your Neon or R2.
How resources work →Deploys & runtimes
Push, upload or let an agent do it. Node needs no config; anything else ships a Dockerfile.
How deploying works →Secrets & config
Your repo holds names. The values live on the platform, encrypted.
How config works →Domains & HTTPS
A subdomain the moment an app exists, and certificates that renew themselves.
How addresses work →Monitoring & backups
Live logs, health checks that email you, and nightly dumps to your disk.
How running it works →From bare server to live app
Ten minutes, start to finish.
1
Install it
curl -fsSL https://raw.githubusercontent.com/astrodock/astrodock/main/scripts/install.sh | sh
On a fresh Linux box. It fetches the stack, generates every secret, and starts it.
2
Finish in the browser
Point a wildcard DNS record at the machine. Astrodock shows you the exact record to create, checks it for you, and turns on HTTPS when it lands.
3
Hand it to your agent
Make a scoped key, give it the docs, and ask for the thing you actually wanted.
Being straight with you
What it isn't.
It isn't Kubernetes. One machine, one stack, no cluster. If you need to survive a region going dark, this is the wrong tool.
It isn't built for scale. It's built for the dozens of small things a person or a team actually runs — internal tools, side projects, the thing your agent wrote on Tuesday.
It isn't magic. You still own the machine, the backups and the updates. Astrodock makes each of those one command each.
What self-hosting actually involves →Give it a machine and ten minutes.
Rather not run a server? Tell us you want hosted Astrodock and we'll let you know when it's ready.