Self-hosted · single binary · your VPS

Ship binaries
to production.

Deploy Go, Rust, Next, Nuxt, SvelteKit and TanStack Start apps to a plain VPS as a single executable — or serve a static site straight from a folder. No Docker. No registry. Nothing installed on the server. One command hardens the box — one command deploys. Zero-downtime releases, scale-to-zero and migrations come standard.

Read the docs →
deploy — drydock
$ homeport bootstrap 178.105.67.23
==> hardening · Caddy · homeportd ✓
$ homeport init
==> detected sveltekit — wrote homeport.yaml
$ homeport deploy
==> build → upload → health-checked activate
deployed → https://app.example.com
5 apps docked
4 frameworks
€6.49 per month
15% memory used
0 Docker daemons

Three commands
to a live app

01
$ homeport bootstrap <ip>

Harden the box

A fresh Ubuntu VPS becomes a locked-down host: firewall, key-only SSH, fail2ban, automatic security updates, Caddy for TLS. One command, idempotent.

02
$ homeport init

Point at your app

Detects your framework — Go, Rust, Next, Nuxt, SvelteKit, TanStack Start — and writes a homeport.yaml with the right build command.

03
$ homeport deploy

Ship it

Build the binary, upload it, health-check the new release, flip an atomic symlink. Bad deploy? It reverts itself. Good deploy? Live with HTTPS.

The harbor

One box.
The whole fleet.

Every vessel below is a real app compiled to a single binary and docked on the same server — each in its own hardened systemd unit, served from memory behind Caddy.

hello Go 1 MB :8100
website SvelteKit 13 MB :8101
nuxt Nuxt 26 MB :8102
tanstack TanStack Start 17 MB :8103
next Next.js 81 MB :8104
5 active · 0 failed host memory: 559 MB / 3.8 GB

Why it holds up

Batteries, no bloat

01

No Docker

systemd + Caddy and nothing else. No daemon, no registry, no base-image CVE treadmill. The server runs your binary, not a container stack.

02

Zero-downtime deploys

The new release proves itself on a private port before Caddy flips traffic to it — blue/green for a single app, rolling for replicas. A failed build never reaches a user; the old one keeps serving, and rollback is a sub-second symlink flip.

03

Scale to zero, then out

Quiet apps sleep to near-zero RAM and wake on the first request in about half a second. Busy ones autoscale on CPU between a floor and a ceiling. Serverless economics on a box you rent for a few euros a month.

04

Zero-downtime migrations

A release hook runs your migration on the box before the new code goes live — and aborts the deploy if it fails. Heroku’s release phase, without Heroku.

05

Many apps, one domain

Mount services at paths behind a single host and certificate, or load-balance an internal service on loopback. An API gateway with nothing to install.

06

Hardened, per app

The box gets a firewall, key-only SSH and fail2ban on boot. Each app then runs in a locked-down systemd sandbox — dropped capabilities, a seccomp filter, memory and CPU caps, one writable directory.

07

Automatic HTTPS

Caddy fetches and renews a certificate per domain. Point an A record, deploy, and TLS is already on — sslip.io works if you don’t have a domain yet.

08

Binary or static

Ship a compiled binary — Go, Rust, or a bun-compiled Next, Nuxt, SvelteKit or TanStack Start — or point static: at a built folder and Caddy serves the files directly. SPA or multi-page is auto-detected; a landing page or docs site runs with no process at all.

09

Agent-ready

homeport mcp exposes deploy, rollback, status and the whole fleet view as MCP tools. Hand ops to an AI agent — with the same health-gated, auto-reverting safety you get.

Off-the-shelf

Cargo you
didn’t build

Homeport ships whatever your build step produces — and that needn’t be your own code. Point the build at a released binary and it docks like any other vessel: one hardened unit, HTTPS, health-gated deploys. Here’s the Lightpanda headless browser, live straight from its GitHub release.

homeport.yaml — cargo manifest
app: lightpanda
server: deploy@vps
domain: browser.example.com

# the build just fetches a release — no compile step
build:
  command: curl -fsSL github.com/lightpanda-io/…/lightpanda-x86_64-linux -o server
  artifact: server

run: serve --host {HOST} --port {PORT}
sandbox: relaxed   # runs its own browser sandbox
FETCH

Fetch, don’t compile

The build step is a plain curl. Any released binary — a headless browser, a metrics exporter, a game server — becomes the artifact homeport ships.

HARDEN

Docked like the rest

It still lands in a locked-down systemd unit behind Caddy, health-gated blue/green with sub-second rollback. Off-the-shelf, not off-the-leash.

SANDBOX

Brings its own sandbox

sandbox: relaxed hands back the namespaces Lightpanda needs to run its own Chromium sandbox. Every other app on the box stays strict.

The difference
is the server

Everyone can deploy an app. The question is what's left running on the box afterward — and how many apps fit before it fills up.

HomeportCoolifyKamal
On the serversystemd + Caddy + a bash helperDocker + Postgres + RedisDocker daemon
Platform RAM~0~2 GB baselineDocker overhead
Ships to the boxone binary (scp)containers (registry)images (registry)
Zero-downtime deploysblue/green + rolling, defaultper-service configrolling via proxy
Scale to zerobuilt in, socket-activatednono
Rollbacksymlink flip, instantredeploy containerredeploy image
Access to deployper-app scoped SSH keysweb UI + SSHroot SSH

Dock your app.

A cheap VPS, three commands, and your app is live with HTTPS. Your app, docked.