Reference

Documentation

How Deplyr works, how to self-host it, and how to use everything in it.

What Deplyr does

Code on GitHub to live on your own server, with a database, logs, monitoring and alerts.

Deplyr is an open-source, self-hostable platform. You point it at a VPS you own — an EC2 instance, a Hetzner box, anything running Linux — and it installs what it needs over SSH once. From then on you deploy apps from GitHub, spin up Postgres or Redis, watch health and logs, and get told in Discord or Slack when something breaks.

Two roles are involved, not two VPS — worth keeping straight, but you only need one box to start:

The control plane

Deplyr itself — this web app, its API and a background worker. You run it once, on your own box.

A managed server

A VPS you register through Deplyr to run your apps on — often the same box the control plane itself runs on. It dials out to the control plane and stays connected, so it never needs an open inbound management port.

Most people start with exactly one VPS
The box you install Deplyr on registers itself as your first server — automatically, as soon as you've created your account — so you can deploy right there. No second VPS, and nothing to connect by hand. Add more servers later, only once you actually want to, and run all of them from this one Deplyr instance.
Register a server and deploy Next.js, NestJS, plain Node, or anything with a Dockerfile.
Free <name>.<your-domain> address for every project, or bring your own with automatic Let's Encrypt SSL.
PostgreSQL and Redis on any server, private by default, with health and history charts.
Discord and Slack alerts for downtime, deploys and offline servers, with full delivery history.
A full activity log of every action across every server and project.
Everything sensitive — tokens, credentials, secrets, passwords — encrypted at rest.

Self-hosting the control plane

One command on a fresh VPS. No Docker to install by hand, no config file to write.

Get a small Linux VPS from any provider — Hetzner, DigitalOcean, an EC2 instance, anything. Then run this on it:

bash
curl -fsSL https://raw.githubusercontent.com/deplyr/deplyr/main/infra/install.sh | bash

That's the entire install. It figures out the rest on its own, and prints a URL when it's done.

  1. 1

    Open the URL it printed

    It's just your server's IP address, like http://13.126.137.183. First time, this is a setup page — pick an email and password. That's your one account for this instance; there's no invite flow or public sign-up here, on purpose.

  2. 2

    You're in — and this server is already registered

    Open Servers and you'll find This server already there and connecting — it's the box you just installed on. Deplyr works over plain HTTP on its IP address; no domain is needed to start deploying.

  3. 3

    Add a domain whenever you want (optional)

    Point the domain's DNS A record at your server, then go to Settings → Instance address and type it in. HTTPS is issued automatically within a minute — no reinstall, no editing files on the server.

  4. 4

    Updating later

    SSH back into the box and run the exact same command again. It updates in place — your account, servers, projects and secrets are untouched.

Only ports 80 and 443 need to be open
In your firewall or cloud security group (AWS, GCP, Azure…), allow inbound 80 and 443. That's all — the dashboard and every app you deploy on this server are served through them, by hostname. Most VPS providers (DigitalOcean, Hetzner, Vultr…) have no firewall by default, so there's nothing to do at all. (Port 4000 is only needed if you connect extra servers.)

Connecting GitHub

Deplyr needs read access to the repos you want to deploy.

There are two ways to connect it — pick whichever fits your setup:

OAuth app

One-click "Continue with GitHub" for every user. Create an OAuth App at github.com/settings/developers, then set GITHUB_CLIENT_ID and GITHUB_CLIENT_SECRET. The callback URL must match GITHUB_OAUTH_REDIRECT_URI. Scopes requested: read:user user:email repo.

Personal access token

No OAuth app needed — paste a token with the repo scope (or a fine-grained token with read access to Contents and Metadata) from Settings. The easiest option for a private, self-hosted instance.

A dead token logs you out
If a linked GitHub token is revoked or expires, Deplyr detects the 401 the next time it's used, clears the link, and ends the session rather than failing silently. Reconnect from Settings.

Registering a server

Point Deplyr at a Linux box and it does the rest.

From Servers → Connect server, give it a name, an IP address, and either a root password or an SSH private key. Deplyr connects once over SSH and installs Docker, nginx and a small agent — after that it never needs SSH again. The agent dials out to the control plane and stays connected, so the server needs no open inbound management port.

Once connected you get live CPU, memory, disk and load, with history charts from 1 hour to 7 days, and a warning if the agent's heartbeat goes stale.

You don't need this screen to get started: the box running Deplyr is registered for you automatically as This server. Use it when you want more — connect as many additional servers as you like, and run every deploy, database and project across all of them from this one Deplyr instance.

Docker Desktop on a Mac doesn't work as a managed server
Docker Desktop doesn't expose host networking, which deployed apps rely on. Use a real Linux server or VM.

Deploying a project

From a GitHub repo to a running container, with sensible defaults you can override.

Projects → New project picks a server and a repo, then Deplyr detects the framework — Next.js, NestJS, plain Node, or anything with a Dockerfile — along with the package manager (npm, pnpm, yarn, bun), the Node version, and monorepo subfolders. Everything it detects is editable afterwards on the project's Settings tab: install, build and start commands, the root folder, and the health-check path.

Secrets are encrypted at rest, available at both build and run time.
Secrets are never written into your source tree or a Docker image layer.
Every deploy shows step-by-step progress with per-step logs.
A failed deploy can be retried — fix the setting, hit Deploy again.

Databases

PostgreSQL and Redis, one click, private by default.

From a server's Databases tab, create a Postgres or Redis instance: choose the version, port, memory limit, and — for Redis — an eviction policy and persistence mode.

Databases bind to the server's loopback address, reachable only by apps running on that same server. Credentials are never shown by default — reveal them on demand from the database's page, or connect an app to one directly when creating it.

Each database gets its own health status, live stats (connections and cache ratio for Postgres; hit rate and memory for Redis), history charts, and container logs.

Domains & SSL

A free address for every project, or bring your own with automatic HTTPS.

Every project gets a free <name>.<your-domain> address the moment it deploys. Add your own domain from the project's Domains tab and Deplyr shows you the DNS record to create, verifies it automatically once it propagates, and issues a real Let's Encrypt certificate — no wildcard certificate needed for custom domains, and it renews itself from then on.

The free default address needs a wildcard certificate for HTTPS
Without one configured on the control plane (DEPLYR_WILDCARD_CERT_PEM / _KEY_PEM), the free *.your-domain addresses serve over HTTP only. Custom domains always get a real certificate automatically, independent of this.
Not the same domain as the dashboard itself
This is a domain for a deployed project. Pointing a domain at Deplyr's own dashboard — the thing you're reading this in right now — is a different, simpler setting: see Settings → Instance address, covered in Self-hosting above.

Notifications & Activity

Know the moment something breaks, and see everything that's happened.

Add a channel from Notifications in the sidebar. You'll need a webhook URL:

Discord: Channel settings → Integrations → Webhooks → New Webhook.
Slack: an app with Incoming Webhooks enabled.

Deplyr sends a test message before it saves the channel, so a broken webhook is caught immediately — editing a channel's webhook later works the same way. Every attempted delivery, including failures and why, shows up in the channel's history.

Separately, the Activity page logs every action across every server and project — deploys, database changes, installs, agent connects, secret changes, alerts — filterable and searchable in one place.

Environment variables

What the installer sets for you, and what each one actually does — rarely worth touching by hand.

infra/install.sh generates all of these on first install. The only one you'd normally change afterward is the domain, and that's done from Settings → Instance address now, not by editing this file — see Self-hosting above.

VariableAppPurpose
DATABASE_URL, REDIS_URLapi, workerPostgres and Redis connections
DEPLYR_MASTER_KEYapi, worker32-byte base64 key that encrypts stored secrets — must match on both
DEPLYR_SESSION_SECRETapiSigns login sessions
GITHUB_CLIENT_ID / _SECRET / GITHUB_OAUTH_REDIRECT_URIapiOptional GitHub OAuth
WEB_URLapi, workerPublic URL of the web app — CORS, redirects, links in alerts
DEPLYR_CONTROL_PLANE_WSworkerPublic ws(s)://…/agent/ws URL agents dial back to
DEPLYR_APP_DOMAINworker, webBase domain for deployed apps (my-app.<domain>)
DEPLYR_WILDCARD_CERT_PEM / _KEY_PEMworkerOptional wildcard certificate for HTTPS on the free default addresses
API_URL, NEXT_PUBLIC_API_URLwebServer-side URL of the API, and the browser's path to it — /api on whatever address you opened Deplyr at, so IP and domain both work
DEPLYR_WEB_PORTcaddyHost port for the dashboard — 80 by default

Security model

What's encrypted, what's logged, and what isn't.

GitHub tokens, SSH credentials, secret values, database passwords and webhook URLs are all AES-256-GCM encrypted at rest using DEPLYR_MASTER_KEY.
Secret values are never logged — the activity log records which secret was touched, never its value.
Notification webhooks are restricted to Slack's and Discord's real hosts, so a saved URL can't be used to make the server call arbitrary addresses.
Databases bind to 127.0.0.1 on the managed server — never exposed publicly.
Losing DEPLYR_MASTER_KEY means losing everything it encrypted
There's no recovery path for a lost master key — back it up somewhere safe, separate from the database backup.
The control plane runs over plain HTTP by default
Unless you put a real domain in front of it (Caddy issues HTTPS for you automatically in that case), the session cookie and any SSH credentials you paste travel unencrypted. Use a domain, or your own TLS-terminating reverse proxy, for anything beyond local testing.

Status & known limitations

Deplyr is early alpha — worth knowing before relying on it.

Not yet validated end-to-end on a real remote Linux server — each piece works against real Docker and GitHub, but the full path through nginx, SSL and the post-deploy health check on a fresh VPS is the current milestone.
The agent image needs publishing (infra/publish-agent.sh) before first use, and after any change to the agent itself.
Apps on the server Deplyr itself runs on get a free address like myapp.13-126-137-183.sslip.io over plain HTTP (sslip.io is a public wildcard-DNS service). HTTPS needs a domain you own — set DEPLYR_APP_DOMAIN to one whose wildcard DNS points here. Attaching a separate custom domain to an app on that server isn't supported yet; use an extra server for that.
Databases are private-only — no public exposure or firewall management yet; connect from your machine over an SSH tunnel.
Your app must listen on $PORT — Deplyr assigns the port and sets it for you.
An existing managed server needs its agent updated when the agent's own commands change.