Production
Your apps in production
Most cloud coding tools let you build but not run — the sandbox resets, the laptop sleeps, there's nowhere for the thing to live. Wrkr is the opposite: your machine is a real, always-on server. So "going to production" isn't a separate deploy product you have to learn. It's just your app running, with a domain pointed at it.
And you don't hand-manage the machine — you tell your agent what you want, and it does the work on the box.
Your app just keeps running
Your machine doesn't sleep, so anything running on it keeps serving — through disconnects, overnight, indefinitely. Start an app and it stays up.
Want it to restart itself if it crashes, or come back after a reboot? Just ask your agent — "keep my app running and restart it if it goes down" — and it sets that up on the machine for you. You don't need to know how it's wired; that's the whole point of having the agent on the box.
Put it online
Publishing a running app is one command:
wrkr expose --port 3000 # → https://<name>.apps.wrkr.dev
wrkr expose --port 3000 --domain app.example.com # → your own domain
Bring a domain from any registrar; wrkr expose --domain prints the DNS record to
add and serves your app there with TLS. Or just tell your agent "put this online
on app.example.com" and it runs the same thing. Full details:
Ingress & custom domains.
The whole stack, one box
A production app needs more than a web server. On Wrkr the rest is already here, on the same machine — your agent wires each piece into your app as you need it:
| Need | On Wrkr |
|---|---|
| Database + vectors | wrkr db — Postgres 18 + pgvector |
| Cache / sessions / rate limits | wrkr cache — Redis |
| User uploads & files | wrkr storage — durable object storage |
| Transactional & inbound email | wrkr email |
| Public HTTPS + your domain | wrkr expose |
| Scheduled jobs | cron |
One machine. One bill. No cross-service glue, and no five dashboards to reconcile when something breaks.
Secrets
Your app's keys and secrets live in your VM, in your project — never with Wrkr. Your agent reads them from the environment as it writes your app; you don't hand them to anyone. That's the whole custody story, and it's on Trust.
Keeping an eye on it
- Are you within your plan —
wrkr statustells you whether your machine is running within its plan; it watches memory pressure and warns you before you run out. - What your app is doing — its logs live on your machine. Ask your agent "why did that last request fail?" and it reads them for you.
There is deliberately no Wrkr logs dashboard or deploy console — that would just be another thing to babysit, which is exactly what Wrkr exists to remove.
How much one machine handles
Your machine (4 cores / 16 GB / 200 GB, always-on) is sized to build, serve, and
grow a real indie app — which is the large majority of what gets built here. Your
app and its whole stack share the box. If it ever starts to feel tight, wrkr status warns you you're nearing your plan, and your agent can tune the app.