How seenode works
What seenode does when you deploy, where the boundary sits between your code and the platform, and the trade-offs behind that line.
Last updated September 18, 2026
seenode takes an application from Git (or a Docker image) to a running service, and keeps it running. This page is about where the line falls between what you own and what the platform owns.
The problem it addresses
Running an application on a server you rent yourself is a pile of jobs that never quite end: install a runtime, supervise the process, put a reverse proxy in front, renew TLS, and 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, how it is built, and (for a process) how it starts.
What happens when you deploy
For a web, worker, or private app from Git, seenode pulls the connected branch, runs your build command on a language runtime image, runs your start command, and (for web) routes public HTTPS to the port you set.
Those two commands are the boundary. seenode doesn’t guess how to install dependencies or launch the process. Everything past the start command belongs to the platform: the container, the certificate (web), load balancing, and an ephemeral filesystem replaced on every deploy.
A static site stops earlier: build command, then files in the publish directory are served. No start command, no container at request time. See Static sites.
You can skip the Git build on web, worker, and private apps and deploy a Docker image you already pushed.
Web services walks through ports, 0.0.0.0, and scaling.
The pieces you assemble
Four application types plus databases: static (files from Git), web (public HTTP), worker (no public URL), private (HTTP on the workspace network only), and managed PostgreSQL / MySQL. See Choose a service type.
What it deliberately doesn’t do
It doesn’t scale itself. You pick an instance size or a replica count. There is no traffic-based autoscaling. Static sites have no replicas.
It doesn’t bill by traffic. Compute services have a fixed monthly price for their size, deducted daily from a prepaid credit balance. Static hosting is $0. Traffic and request volume don’t enter into it.
Those are the same decision. 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. See Pricing and billing.
Where to go next
Deploy your first app
Put the model into practice: a live HTTPS URL in about 5 minutes.Choose a service type
Static, web, worker, private, and databases — with a decision flowchart.Static sites
HTML, CSS, and JS from Git. $0 hosting.Web services
The deploy lifecycle, routing, scaling, and networking in detail.