Someone described a tool to an assistant and got one. Tinycloud is where it goes to live: one link, opened with a work login by exactly the people who should see it, running on a server the company controls. Every app is a jailed Firecracker microVM behind an authenticated gateway. No app ever holds a vendor credential or a database password.

Core concepts

Organizations, apps, environments, deployments, and the four token audiences — the vocabulary every other page assumes.

Install a server

One DNS record and one script on a Debian/Ubuntu KVM host.

Deploy your first app

Bootstrap an organization, validate a manifest, and ship hello-private.

tiny.yaml reference

Every field, every default, and the rules that reject a manifest.

​
The request path

The gateway strips client-supplied platform headers, mints a short-lived audience-bound identity token, wakes sleeping deployments, and proxies the request. The guest runtime verifies that token and builds the per-request SDK context.

​
What the platform guarantees

An app calls named broker capabilities. The host holds the secret, resolves and pins the egress hostname once, and refuses any name that resolves into a private range. See Capabilities.
A microVM is replaceable, so durable data lives outside it. context.db sends SQL across the VM’s private link to the control plane carrying the deployment’s own workload token, and the control plane resolves that token to exactly one environment’s database. See Databases.
An app is reachable without a session only when its manifest says visibility: public with requireLogin: false, and an owner has turned on allowPublicApps for the organization. Such a request carries no identity token at all, so context.user is null. See Access and sharing.
A manifest with build.command boots a second, throwaway microVM first. It runs the build with a firewall hole to the package registry and nothing else, re-scans the output for credentials, and returns an artifact — so a rollback returns to the exact bytes that were served, not to a rebuild that might resolve dependencies differently today. See Builds.

​
Tinycloud is a server platform

The control plane and the application runtime run on a remote Linux/KVM host. macOS and local application execution are not supported, and there is no tiny dev command. The CLI is a remote client and runs anywhere with Node.js 22.18+ and pnpm 10.

​
What the current target supports

Python and containers exist in the schema and provider contracts but are not deployable on the current target. SQLite and object storage need no extra infrastructure; builds, Postgres, and direct egress each depend on operator configuration.
The platform reports these honestly rather than failing halfway through a deploy. Query GET /v1/platform/capabilities before generating or deploying an app, and tiny plan refuses upfront.

​
Design commitments

1

Planning never mutates

tiny plan never touches provider or application state.
2

Deployments are idempotent

They switch traffic only after health checks pass.
3

Artifacts, not paths

Remote deploys use bounded, content-addressed artifacts rather than server-side file paths.
4

Identity is audience-bound

Tokens are minted for the target app and verified inside the guest. A token minted for one boundary is rejected at another.
5

Isolation is a host boundary, not a convention

Firecracker always runs through the jailer with KVM, cgroup limits, seccomp, and per-VM TAP/nftables policy.
6

Deletion is deliberate

Archive snapshots first; deletion requires the exact slug and a grace period.
Read the reasoning behind these in the architecture decision records.