Self-hosted delivery, one binary

Ship it the moment you push.

MELD deployr turns one ordinary server into a deployment platform. Push a branch and it builds, health-checks and swaps your app into place — with TLS, rollback and zero dropped requests. No cluster. No agents. No YAML sprawl.

One static binary · SQLite · Docker · runs on a 2 GB VPS

~/meld-estate — deployr push
0requests through a live cutover with zero failures, measured in deployr's own test suite
0connections during a daemon upgrade — the sockets are handed over, never closed
0from a bare Ubuntu box to your first deployed application
0to install, back up and upgrade. That is the whole platform

From nothing to serving

Three commands, then deployr push forever.

There is no control plane to stand up and nothing to install on the machine beyond Docker. The binary is the platform: edge proxy, git remote, build runner, scheduler and dashboard, in one file.

1

Put the binary on a server

We send you one file. Copy it to any Linux box with Docker and start it — it creates its own database, its own network and its own certificates on first boot.

# any Linux box with Docker scp deployrd server:/usr/local/bin/ deployrd --config /etc/deployr.yml
2

Create an app

Name it, give it a hostname. deployr requests the certificate the first time somebody asks for that name.

deployr apps create api -p acme deployr -a acme/api domains \ add api.acme.com
3

Push

Link the directory once, then push. That runs your pipeline, builds an image, starts the new version beside the old one and swaps traffic when it is healthy.

deployr link acme/api deployr push # or, since deployr is a git remote: # git push deployr main
$ deployr push

The part everyone gets wrong

Nobody notices you deployed.

Your running version keeps serving while the new one starts, gets probed and proves itself. Traffic moves only when it passes — and moves back just as fast if you change your mind.

MELD deployr edge ▲ clients BLUE · v41 web·0 web·1 GREEN · v42 web·0 web·1 health check 100% live traffic

Step 01

v41 is serving.

Two replicas in the blue slot, behind deployr's edge. The certificate is already issued and renewing itself. This is a normal Tuesday.

Step 02

You push. v42 starts beside it.

The pipeline runs, the image builds, and the green slot comes up on the same network — with the same volumes, the same environment, and none of your traffic.

Step 03

It has to prove it works.

deployr probes every new replica until it answers correctly. A version that never becomes healthy never gets a single request — the deployment fails, and v41 carries on as though nothing happened.

Step 04

Traffic moves. Old slot drains.

The routing table is swapped atomically. Requests already in flight finish against v41; new ones go to v42. In our own tests, 7,134 requests crossed this moment without a single failure.

Step 05

Changed your mind?

deployr rollback puts v41 back the same way it arrived — health-gated, drained, atomic. The old image is still on the machine, so it takes seconds, not another build.

Built from real work

What people actually run on it.

deployr was not designed in the abstract. Every capability here exists because a real application needed it on a Tuesday afternoon.

The whole platform

Everything you would otherwise assemble.

A proxy, a CI runner, a git server, a certificate manager, a scheduler and a dashboard. One process, one file to back up, one thing to upgrade.

Voices

People who stopped babysitting deployments.

Licensing

Talk to the people
who built it.

MELD deployr is a commercially licensed product, developed and supported by MELD d.o.o. It is not a download you wrestle with alone: tell us what you are running and we will get you licensed, installed and deploying — usually in an afternoon.

Whether that is a dozen client sites, one product with tenants, or the internal tools nobody has had time to host properly, the conversation starts the same way.