Builder Guide
Your container and Postgres database
Extend an app with custom services and a separate Postgres store when the required compute environment is provisioned.
Custom services extend an app with code and a separate Postgres store. The service environment must be provisioned and healthy before these instructions can be used. Creating a SaaS app or downloading the Developer Kit does not by itself prove that a service VM is running.
Firecracker and GPU infrastructure are not yet online in the current launch environment. Treat this page as the service deployment model until the operator confirms compute readiness. Service Postgres is separate from the SaaS core, AI, and logs databases and does not grant direct access to their data.
The container: your code, your rules
The container is a real compute environment attached to your application. Inside it, you're the developer, not the platform's guest:
- Any stack. Run whatever you can run in a container — Node, Python, Go, .NET, a compiled binary, a niche library the visual tools will never wrap.
- Your own endpoints. Expose HTTP endpoints on the container's port and they become part of your product's capability — custom calculations, integrations with systems nobody has a connector for, processing pipelines, whatever your vertical demands.
- Configured, not improvised. Environment variables carry your configuration; CPU and memory limits are declared per container; and the container's lifecycle — pending, running, stopped, failed — is tracked and visible, with deployments logged like everything else on the platform.
The Postgres database: schema freedom
Alongside the platform's managed data engine, your application gets a Postgres database of its own. It exists for the data that doesn't want to live in a configurable record system: a bespoke relational schema, high-volume ingest from a device fleet, a data structure with twenty years of ecosystem tooling behind it. It's real Postgres — the full ecosystem applies — and its schema is whatever you say it is.
Two connection modes cover both directions of ambition: managed, where the platform hands your container its scoped connections, and external, where your container talks to databases you operate elsewhere. Start managed; the external mode means even “we already have infrastructure” isn't a wall.
Wiring your code into the product
Custom code that can't reach the product is a science project. Yours can be wired in at every layer:
| From | How it reaches your code |
|---|---|
| Pages | Data-bound blocks can resolve through a Postgres connector, so a canvas component can display data your custom schema holds — under the same key-based binding model as everything else. |
| Workflows | Workflow steps call your endpoints, making your custom logic a first-class participant in automations. |
| Your app's API | Your container calls back into the application the same way any integration does — as an API client you issue, with scopes you choose. |
The boundaries that still hold
Freedom inside the container doesn't dissolve the platform's rules around it:
- Platform data access still goes through the platform. Your code reading application records does so through the API, as an authenticated client — which means the permission model, the access logging, and every guarantee in the security architecture apply to your code exactly as they apply to anyone else's. The container extends the product; it doesn't tunnel under it.
- Resources are bounded. Declared CPU and memory limits mean an experiment gone wrong in your container is your container's problem, not your users' outage.
- Everything is logged. Container deployments and lifecycle events land in the application's history like every other operational event.
Contained means contained
Freedom inside the container is matched by hard walls around it — and the walls are worth understanding, because they're what makes it safe to hand every builder real compute in the first place.
No escape upward. The container is a genuine isolation boundary, not a chroot with ambitions. Your code has no path to the host, to the platform's runtime, or to other builders' containers. Whatever runs inside — including a dependency you didn't vet as closely as you meant to — stays inside.
No sight sideways. The container is not dropped onto the platform's network to be fenced in by firewall rules. Instead, it joins a private overlay network — the identity-based, WireGuard-encrypted model Tailscale popularized — where the container has its own cryptographic identity and an explicit access list defines the only internal services it can reach: its own Postgres database, its application's API, and nothing else. Everything else in the system isn't blocked from the container's point of view; it's invisible. There is no address to scan, no port to probe, no neighboring service to discover, because reachability is granted by identity, not implied by being on a network.
The practical consequence is what security reviewers actually ask about: a fully compromised container is a dead end. It can talk to its own database and make authenticated, permission-checked, logged API calls as the client you issued it — the same two things your legitimate code can do — and nothing more. Lateral movement requires a network to move laterally through, and from inside the container, that network doesn't exist.
This is the same discipline applied twice: appliances get their outbound reach frozen in a manifest; your container gets its inbound view of the platform bounded by the overlay's access list. Different trust postures, same principle — nothing reachable by default, everything reachable on purpose.
Container vs. appliance: which one is this?
The platform has two container stories, and they're opposites on purpose:
| Your container (this page) | Marketplace appliances | |
|---|---|---|
| Whose code | Yours — you wrote it, you trust it | A third party's — you're installing a product |
| Freedom model | Open: any stack, your endpoints, your schema | Sealed: endpoints and network reach frozen in a manifest at release |
| Accountability | You audit your own code | The platform audits it for you — fingerprints, egress logs, disclosure ledger |
Same substrate, opposite trust postures: maximum freedom for code you wrote, maximum verification for code you didn't. If you productize what you build here, the selling pipeline is how it graduates into the second column for everyone else.
This included container is distinct from the dedicated container-only runtime topology, which remains a premium option for regulated workloads needing physical isolation of the entire application runtime. Every app gets the extension container described here; the dedicated topology is a deployment choice on top.
Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.