Serverless
Four primitives, one account.
Key-value, SQL database, functions and scheduled tasks, with the API surface you already know and on our own infrastructure. Managed from the panel and over API, CLI and MCP.
$truo serverless fn deploy ./worker.js --name checkout
→ deployed · KV binding: sessions · DB binding: orders
→ fully isolated: nothing persists between invocations
What you get
Four services
kv · db · fn · cron
Bought separately, sharing one account, one invoice and one tenant token.
No rewrite
The same API surface
The queries and calls you already wrote port over untouched.
Isolation
Full isolation per invocation
Each function run is isolated from the rest, with nothing shared between invocations.
Agent-operable
Panel, API, CLI and MCP
Manage them from the panel, and fully through the public v1 API, with an SDK, a CLI and a local MCP.
The primitives
Four pieces that compose
Each is bought on its own, but they are meant to be used together: a function reads from key-value, writes to the database, and a scheduled task fires it.
Key-value
kv.truo.cloud
put, get and list with prefix and cursor, TTL, metadata and idempotent delete.
Workers KV surface
Database
db.truo.cloud
SQL with prepare, bind, first, all, run and batch, plus meta.changes and last_row_id.
D1 surface
Functions
fn.truo.cloud
export default { fetch(request, env) }, with env.KV and env.DB injected.
Workers surface
Scheduled tasks
cron.truo.cloud
Five-field UTC cron expressions firing HMAC-signed webhooks.
Cron Triggers surface
Plans
The same ladder across all four services
One plan per service. The included quotas change; the price does not.
Free
$0/mes
Get startedDev
$5/mes
Get startedStartup
$15/mes
Get startedBusiness
$40/mes
Get startedScale
$150/mes
Get started
Beta: all four services currently run a single replica on a single node, and the function engine depends on one host. There is no high availability and no Service Level Agreement. Your data is backed up: your function code is replicated continuously and a fresh replica starts in under a second, but while that host is down, functions do not execute.
Every plan has a cap: once the monthly quota runs out the API answers 429 and the scheduled run is marked as skipped in the log. No overage is billed. The Free plan is also not covered by the Service Level Agreement.
If you hit the cap, upgrading lifts it right away: the service does not wait for next month.
Quotas
What each plan includes
By service, with what happens at the cap at the foot of each table.
Key-value
kv.truo.cloud
Workers KV surface
| Included | Free | Dev | Startup | Business | Scale |
|---|---|---|---|---|---|
| Reads per month | 1 M | 10 M | 50 M | 200 M | 1,000 M |
| Writes per month | 100 k | 1 M | 5 M | 20 M | 100 M |
| Storage | 256 MB | 2 GB | 10 GB | 50 GB | 250 GB |
At the cap · The API answers 429 until next month or until you upgrade.
Database
db.truo.cloud
D1 surface
| Included | Free | Dev | Startup | Business | Scale |
|---|---|---|---|---|---|
| Databases | 3 | 10 | 25 | 50 | 200 |
| Rows read per month | 25 M | 250 M | 1,000 M | 5,000 M | 25,000 M |
| Rows written per month | 1 M | 10 M | 50 M | 250 M | 1,000 M |
| Storage | 500 MB | 2 GB | 10 GB | 50 GB | 250 GB |
At the cap · Queries answer 429 until next month or until you upgrade.
Functions
fn.truo.cloud
Workers surface
| Included | Free | Dev | Startup | Business | Scale |
|---|---|---|---|---|---|
| Functions | 5 | 20 | 50 | 200 | 1,000 |
| Invocations per month | 100 k | 1 M | 5 M | 25 M | 100 M |
At the cap · Invocations answer 429 until next month or until you upgrade.
Scheduled tasks
cron.truo.cloud
Cron Triggers surface
| Included | Free | Dev | Startup | Business | Scale |
|---|---|---|---|---|---|
| Schedules | 5 | 25 | 100 | 500 | 2,500 |
| Runs per month | 5 k | 50 k | 250 k | 1 M | 5 M |
At the cap · Runs are marked as skipped until next month or until you upgrade.
Every invocation runs fully isolated
This is what makes running third-party code defensible: every run starts clean and leaves nothing behind for the next one.
- ●
No network interface
The execution environment has no network card: everything in and out goes through a controlled channel to the platform.
- ●
Tokens never enter the execution environment
A platform-side relay injects them, and validates that the namespace requested is the one in the binding.
- ●
Outbound traffic with a policy
fetch goes out through that relay: private IPs, link-local and cloud metadata are denied, with DNS resolved platform-side.
- ●
No state between invocations
The environment resets when it finishes. Nothing survives from one invocation to the next, or across customers.