Skip to content

Docs

Services

Managed compute. A service is your process — a Nuxt server, a Go API, a worker — running in a microVM of its own on our hardware, with a TLS address in front of it. You choose a size, you deploy a build, and the platform keeps it running. Sites and Services are the same product family: a site serves files, a service runs a process.

Deploy a service

The CLI is the path. It looks at your build output, works out whether it is a static folder or something that needs a running process, and deploys accordingly:

subnomic sites link api --dir .output   # a Nuxt/Nitro build
subnomic sites deploy --prod            # prints the live URL

A deployment is immutable and promoting it is a pointer move, so rolling back is instant. What differs from a static site is what happens after promotion: the platform asks a scheduler for a machine, builds a read-only disk holding your build, boots a microVM and waits for your process to answer on its port.

Sizes

Six sizes, from pico (256 MiB) to large (16 GiB). Each one fixes CPU, memory, disk, network and disk I/O together — they are not tuned separately, because a size that promises memory without the I/O to use it is not a size, it is a surprise.

You can change size later from the service's settings. The change applies on the way back up: the service stops, is re-sized, and starts again on the same machine, keeping its data. Disk only ever grows — shrinking one would mean deciding which of your bytes to drop.

A stopped service still holds its slot on a host, and still counts against your plan. Stopping saves you the process, not the reservation — delete it to free the room.

Managed databases

Add a PostgreSQL or Redis from the catalogue and bind it to a service. The connection string is generated for you and delivered to your process as an environment variable — DATABASE_URL for Postgres, REDIS_URL for Redis — so it never has to live in your repository.

The images are ours and pinned. You cannot point a managed datastore at an image of your own: it would be arbitrary code running with our credentials on our hardware, which is a different product with a different threat model.

There are no automatic backups yet. A managed datastore holds your data on one machine, and nothing snapshots it for you — take your own dumps if the data matters.

What the service sees, and what can see it

  • No shell. Your build arrives as a read-only disk built before the machine boots. There is no SSH into a service, by design — it is the largest surface a host running customer code can give up.
  • Egress is yours to close. A service may reach the internet or be limited to the workspace's own services. The setting applies at the host firewall, not in your code.
  • Your services can reach each other when they belong to the same workspace. Nobody else's can.

Logs and usage

The service page has three tabs: an overview with CPU, memory, disk and network read from the machine itself, live logs from your process, and settings. The figures are what the host measures, not what your process reports about itself.

Logs are not archived yet: they live with the machine, so a service that is destroyed takes its history with it. Download anything you need to keep.

Plan limits

Three numbers bound compute: how many services may run a process, how large a single one may be, and how much memory all of them may hold together. The third is what stops a workspace from turning many small services into one large bill. Going past any of them refuses the action rather than charging for it.