BASECOVEpreview
Install →

■ Self-hosted · one binary · open for testing

The old version serves until the new one proves itself.

Basecove is a single Go binary for your own server. It builds your app, health-checks it while the current version keeps serving, moves traffic only once the new one passes, provisions its database and watches every route it serves.

Install on a server → Read the docs
memory
~60 MB
disk
~70 MB
binary
1 file · static
proxy
Caddy, built in
https
automatic
databases
pg · mysql · redis
deploy · shop.example.com 00.0s
in flight v4 building
  1. ○Buildnpm ci · build
  2. ○Startport —
  3. ○Health checkGET /health
  4. ○Routeno traffic yet
v3 keeps serving while v4 builds. If v4 never passes, nothing changes.
serving traffic212 req/min
v3 100% ● live
v4 0% ◍ building
build output● following
Colour means state, and nothing else: ◍ starting / healthy, not routed ● live · serving traffic ◌ draining ✕ failed

How it works

Two guarantees, tested on every build.

A deploy runs as copy, install, build, health check, switch, drain. The test suite starts real processes against the real proxy and checks both of these through the edge. It doesn't just read a status column.

01 · in-flight requests● asserted

A request already in flight stays with the version that took it.

When traffic moves to v4, v3 drains rather than stops. A slow request that started on v3 finishes on v3. Only new requests go to v4.

switch v3 drained v4 healthy v4 live slow request → served by v3
02 · failed health check● asserted

A version that fails its health check never gets a request.

A build error, a crash on boot or a health path that won't return 200: any of them stops the deploy before traffic moves. The current version never stops serving.

v4 · 100% of traffic, throughout v5 starting ✕ 503 × 4 · stopped requests to v5: 0

What's in the binary

Everything between git push and a live, watched URL.

deploy

Node, Docker or static

A Dockerfile runs as a container. A package.json with a start script runs natively. A built Vite, React, Astro or plain HTML site is served directly, with no server process.

detect → install → build → start

gate

Hold, then decide

Deploy with a gate and the new version waits at "healthy, no traffic" until you route or discard it. Roll back to any earlier release through the same health check.

healthy → [you] → live

route

HTTPS on every host

An embedded Caddy routes by hostname and gets Let's Encrypt certificates for every app, including the dashboard's own admin hostname. An app can answer on up to 10 more, such as admin., or send www to its domain.

www.shop.example.com → shop.example.com

data

A database on request

Postgres, MySQL or Redis, provisioned with generated credentials and injected as DATABASE_URL. Or attach a managed one by connection string.

DATABASE_URL=postgres://…

watch

Monitoring with no setup step

Basecove deployed the app, so it already knows what to probe. It checks health, tracks per-route errors from real traffic and certificate expiry, and alerts Slack, Discord, Teams or any webhook.

GET /checkout · 5xx 0.0%

git

Deploy on push

Point an app at a repository and pick a branch. A GitHub App covers private repos without a stored token, and a push to the branch you choose starts a deploy. A pushed deploy waits at the gate for you, or goes live once its GitHub Actions tests pass.

push main → v12 gated

Spec sheet

One process. Your server stays yours.

No control plane and no agent phoning home. Basecove's own servers have no inbound access to your machine. The daemon, the proxy, the dashboard and the state database all ship as one statically linked file.

basecove versionlinux · amd64 / arm64
runtime deps
none · static binary
state
embedded SQLite
proxy
Caddy, in-process
tls
Let's Encrypt, automatic
dashboard
served by the daemon
auth
admin · viewer · CI token
native apps
needs Node on the box
containers · dbs
needs Docker on the box
upgrades
verified, auto-rollback
tested on
Ubuntu 24.04

Install

From a fresh server to an HTTPS dashboard in three commands.

You need a Linux server with ports 80 and 443 open, and DNS records for your app's hostname and an admin hostname pointing at it. The full walkthrough covers each step.

  1. 1download & verify
    server · root
    $ curl -fLO https://basecove.name.ng/download/basecove-linux-amd64.tar.gz
$ curl -fLO https://basecove.name.ng/download/SHA256SUMS
$ sha256sum -c --ignore-missing SHA256SUMS
  2. 2install the service
    server · root
    $ tar xzf basecove-linux-amd64.tar.gz && cd basecove
$ ./install.sh --binary ./basecove \
    --host example.com --admin-host admin.example.com
  3. 3create your admin, sign in
    server · root
    $ sudo -u basecove basecove user add you -role admin \
    -data /var/lib/basecove
# then open https://admin.example.com

On an ARM server, use basecove-linux-arm64.tar.gz.

This is a previewread before you rely on it

Test it on a server you can afford to lose.

Basecove runs real apps on a real server today, and we want testers to find what breaks. These are the edges we already know about.

All known limits →
  • A provisioned Postgres app user is a superuser. Treat app code with database access as having full control of that database.
  • Database credentials are stored in plain text in the daemon's SQLite file. Back that file up as carefully as the credentials it holds.
  • A route with little traffic can fail without an alert. Per-route alerts need 20 requests in 5 minutes before they judge a route. The health probe still covers the app as a whole.
  • One server, two global roles. No multi-server fleet and no per-app permissions yet.

Deploy something. Break something.
Then tell us what happened.

Start the quickstart → Deploy your first app