How seenode works

seenode takes an application from a Git repository to a running service on a public HTTPS URL, and keeps it running. This page is about where the line falls between what you own and what the platform owns, and why it falls there.

The problem it addresses

Running a web application on a server you rent yourself isn’t difficult, exactly. It’s a collection of small jobs that never quite end: install the language runtime, keep a process supervised and restarted, put a reverse proxy in front of it, obtain a TLS certificate and renew it before it expires, and wire up some way to redeploy when you push. Then do it again for the next app.

seenode’s premise is that those jobs are close to identical for almost every application, so the platform should own them. What stays yours is narrower: your code, the command that builds it, and the command that starts it.

What happens when you deploy

seenode pulls your code from the connected branch, runs your build command on a prebuilt image for your language, runs your start command to launch the process, and routes traffic to it.

Those two commands are the boundary. seenode doesn’t guess how to install your dependencies or how to launch your server; you say so explicitly, in the same commands you’d run locally. Everything past your start command belongs to the platform: the container, the certificate, the load balancer that terminates TLS and forwards to your port, and the ephemeral filesystem that gets replaced on every deploy.

Web services walks through each stage, including why your app has to listen on 0.0.0.0 and the exact port you configured.

The pieces you assemble

A web service handles HTTP and is the only kind with a public URL. A worker service runs a background process with no port and no public address. A database is managed PostgreSQL or MySQL. They share a private network, so they reach each other without crossing the public internet. See Service types.

What it deliberately doesn’t do

It doesn’t scale itself. You scale vertically by choosing a larger instance, or horizontally by setting a number of replicas that traffic is balanced across. Both are numbers you set. There’s no traffic-based autoscaling, so a spike won’t be absorbed for you, and an idle service won’t shrink to save you money.

It doesn’t bill by traffic. Each service has a fixed monthly price for its size, deducted daily from a prepaid credit balance. Traffic and request volume don’t enter into it.

Those are the same decision, and it’s a real trade-off rather than a straightforward win. A platform that meters usage will ride out an unpredictable spike better than this model does. What you get in exchange is that next month’s cost is knowable today, and a bad afternoon on the internet can’t produce a surprising invoice. If your workload is spiky and your budget is elastic, that trade runs against you. If it’s steady, or your budget isn’t elastic, it runs for you.

See Pricing and billing for instance sizes and prices.

Where to go next