Too much ceremony for a small change
A tiny fix often turned into a full pipeline run, a full upload, and a lot of waiting just to move one small edit onto a server.
About us
Relay came out of a simple frustration: deploying small changes felt heavier than the changes themselves.
The idea behind Relay was not to build another abstract platform. It was to make self-hosted deploys feel tighter, clearer, and less annoying. Sync only what changed. Build on the machine that actually runs the app. Keep the rollout visible. Keep control of the server.
In plain terms
Relay is for people who want deploy lanes without giving away the runtime.
It keeps Docker, routing, and rollout behavior visible instead of hiding them behind a hosted product.
The goal is not more magic. The goal is less friction.
Where it started
A lot of deployment tooling is sold as convenience, but the day-to-day experience can still be frustrating. You make a small change, wait for a large pipeline, send a lot more files than you needed to, then dig through logs that feel disconnected from the actual machine that runs the app.
That gets worse when dev or preview environments only exist inside a hosted platform. They are useful, but they also come with platform-specific rules, hidden infrastructure, and a lot of distance between what you typed locally and what actually happened on the host.
Relay came from wanting the shorter path: one CLI, one server-side agent, differential sync, framework-aware builds, visible Docker logs, and a rollout model you can explain without hand-waving.
What Relay tries to fix
Less waitingSync the changed files instead of re-sending the whole project.
Less abstractionSee the buildpack choice, build logs, readiness checks, and preview URL clearly.
Less lock-inKeep the app, the runtime, and the rollout on infrastructure you already own.
The frustration
Deploying should not feel like rebuilding the world every time.
These were the repeated pain points behind the project, and they still shape the product decisions now.
Preview deploys that felt far away
A lot of tooling gives you previews, but only after you hand over the whole deployment story to somebody else's platform and somebody else's rules.
The real runtime disappeared
Docker, ports, routing, secrets, and rollbacks still mattered. They were just hidden until something broke, which made operations worse instead of easier.
What it became
Relay ended up as a small, opinionated deployment stack.
Not a giant platform. Just a focused set of parts that make the common path feel cleaner.
A CLI that feels direct
The `relay` CLI is meant to feel close to the work: init the repo, deploy it, stream the logs, check status, roll back if needed.
An agent that stays on your server
`relayd` does the heavy lifting on the machine you control. It builds images, runs containers, keeps deployment history, and serves the dashboard.
Docker-first rollouts
Relay is built around a Docker-first path for production. It syncs the delta, builds the image, starts the next slot, checks readiness, then switches traffic.
The point of it
Relay is for teams who want deploys to feel understandable again.
Faster deploy lanes matter, but so does knowing where the container is running, how the rollout happened, and what to do when something goes wrong.