NewTruo Deploy and DBaaS PostgreSQL, live in the TruoCloud panelSee the catalog
Beta · public price, no SLA

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 over API, CLI and MCP.

$truo serverless fn deploy ./worker.js --name checkout
→ deployed · KV binding: sessions · DB binding: orders
→ every invocation runs in its own microVM and is thrown away

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

One microVM per invocation

Each function run happens alone and the machine is discarded when it finishes.

Agent-operable

API, CLI and MCP

Full management lives in 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 started

Dev

$5/mes

Get started

Startup

$15/mes

Get started

Business

$40/mes

Get started

Scale

$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.

The Free plan has a hard cap: once the quota runs out the API answers 429 and the scheduled run is marked as skipped in the log. No overage is billed, and it is not covered by the Service Level Agreement.

On paid plans, overage is billed and never cuts the service off. The number of scheduled tasks is the one exception: it is a hard limit on every plan.

Quotas

What each plan includes

By service, with the overage price at the foot of each table.

Key-value

kv.truo.cloud

Workers KV surface

IncludedFreeDevStartupBusinessScale
Reads per month1 M10 M50 M200 M1,000 M
Writes per month100 k1 M5 M20 M100 M
Storage256 MB2 GB10 GB50 GB250 GB

Overage · $0.60 per million reads · $6.00 per million writes · $0.75 per GB-month

Database

db.truo.cloud

D1 surface

IncludedFreeDevStartupBusinessScale
Databases3102550200
Rows read per month25 M250 M1,000 M5,000 M25,000 M
Rows written per month1 M10 M50 M250 M1,000 M
Storage500 MB2 GB10 GB50 GB250 GB

Overage · $0.005 per million rows read · $1.50 per million written · $0.75 per GB-month

Functions

fn.truo.cloud

Workers surface

IncludedFreeDevStartupBusinessScale
Functions520502001,000
Invocations per month100 k1 M5 M25 M100 M

Overage · $0.40 per million invocations

Scheduled tasks

cron.truo.cloud

Cron Triggers surface

IncludedFreeDevStartupBusinessScale
Schedules5251005002,500
Runs per month5 k50 k250 k1 M5 M

Overage · $1.00 per 10,000 runs. Schedules are a hard limit.

Code execution

Every invocation runs in its own machine and is thrown away

This is what makes running third-party code defensible. It is not a hardened container config: it is a microVM restored from a snapshot for that single invocation.

  • No network interface

    The machine has no network card: everything in and out goes through a local channel to the host.

  • Tokens never enter the machine

    A host-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 host-side.

  • No state between invocations

    The machine is discarded when it finishes. Nothing survives from one invocation to the next, or across customers.

Want to port something you already run and watch how it behaves?