Skip to main content
Tovuk service resources are managed through the CLI, API, and dashboard so agents do not need hidden manual actions.

​
Dashboard

The dashboard Resources view is available at https://tovuk.com/account/resources or https://tovuk.com/<handle>/resources. It can create SQLite databases, KV namespaces, queues, cron triggers, State namespaces, and private service bindings with the same API routes and limits as the CLI. It also lists existing resources, creating and deleting SQLite, KV, Queue, Cron, State, and Service Binding resources through the same API routes as the CLI. The same view can run single SQLite queries through POST /v1/services/{service_id}/sqlite/{database}/query and displays rows, rowsRead, rowsWritten, vmSteps, fullscanSteps, storage, duration, and next actions. It can also list SQLite backups, create SQLite backups, restore SQLite backups, list KV keys, read one KV key, write one KV key, and delete one KV key through the same metered KV API routes as the CLI. It can also send one Queue message and send one Queue batch through the same metered Queue API routes as the CLI, then read Queue messages and read Queue metrics. It can update Cron schedules, pause Cron triggers, and resume Cron triggers through the same API routes as the CLI. It can also list State objects, list State keys, read one State value, write one State value, delete one State value, read State alarms, set State alarms, and delete State alarms through the same metered State API routes as the CLI. Use CLI bulk commands for bulk KV reads, writes, and removals. Dashboard State alarm actions include read State alarms, set State alarms, and delete State alarms.

​
Commands

tovuk service show service_1 --json
tovuk sqlite create --service service_1 DB --json
tovuk sqlite query --service service_1 DB "select 1" --json
tovuk sqlite backup create --service service_1 DB --json
tovuk sqlite backup list --service service_1 DB --json
tovuk sqlite backup restore --service service_1 DB sqlite_backup_1 --json
tovuk sqlite delete --service service_1 DB --json
tovuk kv create --service service_1 CACHE --json
tovuk kv put --service service_1 CACHE user:1 '{"name":"Ada"}' --metadata '{"kind":"profile"}' --ttl 3600 --json
tovuk kv put --service service_1 CACHE session:1 '{"ok":true}' --expiration 1780272000 --json
tovuk kv get --service service_1 CACHE user:1 --json
tovuk kv keys --service service_1 CACHE --json
tovuk kv namespace delete --service service_1 CACHE --json
tovuk queue create --service service_1 jobs --max-retries 3 --retention-seconds 86400 --json
tovuk queue delete --service service_1 jobs --json
tovuk cron create --service service_1 nightly "0 0 * * *" --json
tovuk cron update --service service_1 nightly "*/15 * * * *" --json
tovuk cron disable --service service_1 nightly --json
tovuk cron enable --service service_1 nightly --json
tovuk cron delete --service service_1 nightly --json
tovuk state list --service service_1 --json
tovuk state create --service service_1 Room --json
tovuk state objects --service service_1 Room --json
tovuk state keys --service service_1 Room room-1 --json
tovuk state put --service service_1 Room room-1 counter 1 --json
tovuk state get --service service_1 Room room-1 counter --json
tovuk state delete-value --service service_1 Room room-1 counter --json
tovuk state delete --service service_1 Room --json
tovuk binding create --service service_1 AUTH_SERVICE --target auth-service --json
tovuk binding delete --service service_1 AUTH_SERVICE --json
tovuk limits set build_minutes --period month --value 6000 --notify-at-percent 80 --json
tovuk limits set worker_requests --period day --value 100000 --notify-at-percent 80 --json
tovuk limits set state_requests --period month --value 1000000 --notify-at-percent 80 --json
tovuk limits set state_sqlite_rows_written --period month --value 50000000 --notify-at-percent 80 --json
tovuk limits delete worker_requests --period day --json

​
Resource model

  • Worker: Rust HTTP runtime for public APIs, webhooks, auth callbacks, forms, queue consumers, and cron handlers.
  • Static frontend: browser UI at /, with dynamic work routed to same-origin Rust APIs under /api/*.
  • SQLite: service data with row and storage meters.
  • SQLite query: migrations, smoke tests, and data inspection with metering.
  • SQLite backups: manual restore points and pre-restore safety snapshots for no-dashboard migration recovery.
  • Object storage: user uploads, images, videos, documents, generated files, and downloads.
  • KV: small config, sessions, feature flags, and cache metadata.
  • Queues: background jobs, retries, emails, and webhook processing.
  • Cron triggers: scheduled cleanup, polling, and reports.
  • Builds: pre-deploy checks, release builds, build-minute metering, and deploy promotion.
  • State: keyed state objects for realtime coordination, locks, counters, rooms, sessions, and per-tenant state.
  • Service bindings: private worker-to-worker calls without public URLs.
  • Secrets: server-only environment variables managed with tovuk env.
  • Custom domains: production hostnames with agent-verifiable DNS setup.
  • Logs: build, deploy, and runtime diagnosis for repair loops.
  • Usage caps: hard stops and notification thresholds for predictable usage.
Each service can bind up to 5000 service resources. That count includes SQLite databases, KV namespaces, queues, State namespaces, and private service bindings. Service binding call chains can use up to 32 worker invocations per top-level request, and every service binding call also counts against Worker subrequest limits. The machine-readable product catalog is available from: 
tovuk pricing --json
tovuk usage --json
The catalog commands expose the products array. Use it to decide which resource fits a task, use each product’s features to verify supported behavior, use meters and meter_details to set hard caps with the right units, use pricing_fields to read the relevant plan prices, and use the plan limits and pricing objects to estimate free and paid usage before deployment. The authenticated usage response adds billingEstimate.lineItems for current-month cost planning. tovuk service show <service> --json is the canonical service snapshot for agents. It includes status, deploys, builds, logs, env names, domains, resources, capabilities, accountUsage, billingEstimate, and next actions in one response. Without --json, tovuk service list prints a compact table with Service kind, runtime status, URL, enabled and disabled capabilities, and resource counts. tovuk service show prints a compact Service snapshot with capabilities, resource counts, usage, latest deploy, latest build, and next actions.

​
Runtime bindings

Deployed Rust workers receive service-scoped environment variables at startup: 
TOVUK_SERVICE_ID=service_1
TOVUK_SERVICE_SLUG=my-service
TOVUK_SERVICE_PLAN=free
TOVUK_API_BASE_URL=https://api.tovuk.com
TOVUK_RUNTIME_TOKEN=tovuk_runtime_...
TOVUK_BINDINGS_VERSION=1
TOVUK_SQLITE_DB=sqlite_1
TOVUK_KV_CACHE=kv_1
TOVUK_QUEUE_JOBS=queue_1
TOVUK_CRON_NIGHTLY=cron_1
TOVUK_STATE_ROOM=state_namespace_1
TOVUK_BINDING_AUTH_SERVICE=service_2
Agents should read these variables instead of hard-coding ids. Resource names are uppercased for environment suffixes, so a queue named jobs becomes TOVUK_QUEUE_JOBS, and a State class named Room becomes TOVUK_STATE_ROOM. TOVUK_RUNTIME_TOKEN is injected only into the deployed Rust worker process. It can call Tovuk APIs for the current TOVUK_SERVICE_ID, including resource inspection, SQLite queries, KV reads and writes, queue sends and metrics, State values, and object storage operations. It cannot manage account settings, billing, domains, environment secrets, support tickets, or other services. Never print it, send it to browsers, place it in static frontend files, or store it in source control. Runtime API calls should use: 
curl -fsS "$TOVUK_API_BASE_URL/v1/services/$TOVUK_SERVICE_ID/resources" \
  -H "Authorization: Bearer $TOVUK_RUNTIME_TOKEN"

​
Custom domains

Custom domains use one DNS-only CNAME record: 
tovuk domains add --service service_1 api.example.com --json
tovuk domains verify --service service_1 api.example.com --json
The API response includes dns_record_type, dns_record_name, dns_record_value, dns_setup_url, and agent_instruction so agents can configure DNS through the user’s DNS provider API without dashboard access. Never point an A record at Tovuk origin hosts. Delete commands return the refreshed service resource payload so agents can verify cleanup immediately and continue without dashboard checks. KV keys follow the Tovuk 512 byte limit and may include path separators when the CLI or API client URL-encodes them. Use object storage for values larger than 25 MiB. Bulk KV reads accept 100 keys; bulk writes and deletes accept 10000 keys, and bulk request bodies must fit 100 MB. Use object storage commands for service files and media: 
tovuk storage list --service service_1 --json
tovuk storage upload --service service_1 ./logo.png uploads/logo.png --public --json
tovuk storage download --service service_1 uploads/logo.png ./logo.png --json
tovuk storage delete --service service_1 uploads/logo.png --json
tovuk limits set object_storage_class_a_operations --period month --value 1000000 --notify-at-percent 80 --json
tovuk limits set object_storage_class_b_operations --period month --value 10000000 --notify-at-percent 80 --json
tovuk limits set object_storage_egress_bytes --period month --value 1000000000000 --notify-at-percent 80 --json
tovuk storage upload automatically switches to multipart transfer for files larger than 100 MiB. Queue messages are capped at 128 KB total. Tovuk reserves 100 bytes for Tovuk queue metadata, so the maximum user body is 127900 bytes. Store larger payloads in object storage and send the storage path in the queue message. Queue specs follow Tovuk limits for 100 message consumer batches, 100 message send batches, 256 KB send-batch payloads, 60 second batch waits, 5000 messages per second per queue, 25 GB backlogs, 250 concurrent consumers, 12 hour visibility timeouts, 24 hour send delays, and 15 minute consumer wall time. Agents can tune queue delivery without a dashboard: 
tovuk queue create --service service_1 failed_jobs --json
tovuk queue create --service service_1 jobs --max-batch-size 10 --max-batch-timeout-seconds 5 --dead-letter-queue failed_jobs --json
tovuk queue update --service service_1 jobs --max-batch-size 25 --max-batch-timeout-seconds 10 --json
tovuk queue update --service service_1 jobs --clear-dead-letter-queue --json
The dashboard Resources view can update Queue retries, retention, batch size, batch timeout, and dead-letter Queue settings through PUT /v1/services/{service_id}/queues/{queue}. It can also read Queue messages, read Queue metrics, send one Queue message, and send one Queue batch with queue_operations metering. State usage is metered with Tovuk counters: state_requests, state_duration_gb_milliseconds, state_sqlite_rows_read, state_sqlite_rows_written, and state_sqlite_storage_bytes. Duration is recorded in GB-milliseconds so agents can set precise integer caps without rounding short requests to full GB-seconds. State values are addressed by namespace, object key, and state key. Use workers for public HTTP APIs, then call State only when one key needs serialized coordination: 
tovuk state list --service service_1 --json
tovuk state objects --service service_1 Room --json
tovuk state keys --service service_1 Room room-1 --json
tovuk state put --service service_1 Room room-1 counter 1 --json
tovuk state get --service service_1 Room room-1 counter --json
tovuk state alarm set --service service_1 Room room-1 --delay-seconds 60 --json
tovuk state alarm get --service service_1 Room room-1 --json
tovuk state alarm delete --service service_1 Room room-1 --json
tovuk state delete-value --service service_1 Room room-1 counter --json
State keys are capped at 512 bytes. The state key and value are capped at 2 MiB combined. Free State objects get 1 GB per object. Pro State objects get 10 GB per object. Free also has a 5 GB account cap, so total Free State storage stops earlier. Each State object can hold one scheduled alarm. Setting a new alarm replaces the previous one. Use --delay-seconds for relative scheduling or pass a UNIX millisecond timestamp for an absolute schedule. Alarm delivery is at least once; failed handlers retry with exponential backoff from 2 seconds and stop after 6 retries. Alarm handlers have a 15 minute wall-clock limit.

​
Worker delivery

Agents create resources through CLI/API commands. Deployed Rust workers receive runtime events through internal HTTP endpoints:
  • POST /.tovuk/queues/<queue> receives a JSON batch with base64 message bodies.
  • POST /.tovuk/cron/<trigger> receives { "name": "...", "cronExpression": "..." }.
  • POST /.tovuk/state/<class>/<object>/alarm receives alarm metadata with retryCount and isRetry.
  • Tovuk records worker request, worker CPU, State request, State duration, and queue operation meters for delivered events.
  • Tovuk wakes cold workers before delivery, retries failed queue batches, and expires messages at the queue retention limit. Messages that exhaust retries move to the configured dead-letter queue when one is set. State alarms that exhaust retries are cleared.
Use these endpoints only inside deployed workers. Browser frontends should call the same-origin Rust API under /api/*. Public traffic to /.tovuk/* is blocked by the router.
Last modified on June 3, 2026