Skip to main content
The hard part of turning an idea into working software usually isn’t the code. It’s everything the code needs in order to run: somewhere to keep data, a way for people to sign in, somewhere to put uploaded files, an address on the internet. Workser Code brings these services into the project workspace. Provision the resources your app needs, and check their status before depending on them. Apps in the same project share its resources; your organization’s plan sets the included capacity.

Data

A dedicated Postgres database (Neon-backed) for each project — not a shared table with other customers.

User

Managed authentication for your app’s own users, with no user cap.

Files

A storage bucket per project for uploads, exports and generated assets.

Web

A stable *.workser.app address from the first publish, plus custom domains.

Connected apps

Gmail, Slack, Google Sheets, Stripe and more — connected once, usable by every app in the project.

Keys & secrets

Environment variables managed for you, so nothing sensitive ends up in the code.

​
Data

Each project gets its own Postgres database. Your agent can create it, inspect it, and query it while building:
The database belongs to the project, not to a single app. If a project has several apps, they share it — which is exactly what you want when your storefront and your admin tool are looking at the same orders.
Review data changes. Destructive queries use the applicable approval policy. Plan schema changes as migrations, inspect their effect and confirm a recovery path before changing production data. See Security & approvals. Connection strings are credentials. workser db url returns a least-privilege connection string, and the running app gets it from its environment automatically. It should never be pasted into a chat or committed to a file.

​
User

Your app’s users sign in through Workser-managed authentication. There’s no user limit on any plan — you’re not billed per person who signs up for your app. At runtime, your app looks users up through the SDK: workser.auth.

​
Files

Every project has a storage bucket (Cloudflare R2 behind Workser).
Like the database, the bucket is per project and shared by its apps, so keys should be namespaced (invoices/2026/…) rather than dumped at the root. For app uploads at runtime, the app uses workser.storage from the SDK — and for large files it should request a presigned upload URL so the bytes never travel through Workser.
These are two different stores, and a file in one is not visible in the other.
  • workser storage — the default bucket every project has. This is the normal answer.
  • workser neon storage — S3-compatible object storage on the project’s own Neon branch, so it branches along with the database. It also offers Node.js HTTP functions (workser neon functions).
The Neon backend is additive and only available on dedicated tenancy in a supported region. Region is fixed when the project is created, so regionSupportsNeonBackend: false is final rather than something to retry. Run workser neon status before assuming it’s there; most apps never need it.

​
Web & domains

Publishing gives you a stable *.workser.app address that does not change between deploys — safe to send to customers, print on a card, or point a domain at.
Custom domains are included on Spark, with plan-specific allowances on higher tiers. Purchase the domain separately and configure its DNS records. Attaching a domain alone does not finish DNS setup.
Domain changes use the applicable desktop approval policy. Reserved Workser and provider hostnames are refused. See Security & approvals.

​
Connected apps

Authorize Gmail, Slack, Sheets or another available tool for the project. Your coding agents can use it while developing and maintaining software, and your finished apps can call its actions from their backend. Workser manages the connection; your app still owns its end-user permissions. See App connections.
app run can have a real side effect in a real account. Review the available action, its inputs and the applicable authorization before sending messages, changing records or moving money. Desktop approvals do not automatically protect SDK calls made by your deployed app.OAuth can never be completed on your behalf — connecting an account always requires you to open the link yourself.

​
Keys & secrets

Setting an environment variable writes a value without your agent ever reading it — which is the point. When you have a secret to add, set it yourself in Workser Code or run env set rather than pasting the key into a conversation. Deleting an environment variable is an owner action.
env configures the cloud environment (production and preview). The .env files inside the app folder configure your computer — you edit those in Workser Code under Settings → “On this computer”, and saving there restarts the local dev server. They’re different environments; changing one doesn’t change the other.

​
Automations that outlive a request

Some work shouldn’t happen while a customer is waiting — a nightly summary, a slow export, a multi-step follow-up.
The app triggers a workflow at runtime through workser.workflows in the SDK.
A workflow feature is two-way, and the return half is the one people forget. Triggering the workflow is outbound. When the workflow produces something the app needs, its final node has to POST back to a webhook route in your app. Build only the trigger and the workflow runs perfectly while nothing ever appears in the product.

​
Business records

Projects also carry Workser’s business hub — products, orders, customers, sales pipelines, pages, campaigns, support conversations and more. These are the same rows the Workser dashboard and your AI employees read and write.
An app built on Workser isn’t integrating with a separate system — it’s reading its own business. Don’t build a parallel table for something the business hub already models.

​
Capacity and cost

Your plan includes database storage, file storage and monthly egress. App user authentication has no user cap on the published paid plans. Database and file allowances are pooled across your organization’s projects. Published overage rates are 1.25/GBfordatabasestorage∗∗,∗∗1.25/GB for database storage**, **0.15/GB for files and $0.50/GB for egress, where the corresponding usage meter is enabled. Read Plans and cloud usage for the full comparison and account-specific billing caveats.

​
Next

Preview & publish

How changes get from your agent to your customers, and how to undo one.

The SDK

How the deployed app reads all of this at runtime.