Dora NodaMost self-hosted PaaS tools sell you a friendlier way to write a Dockerfile. Devpush's pitch is that you never write one at all: git push, and a FastAPI app orchestrating Docker under the hood figures out the rest. It's a narrower, more opinionated bet than the buildpack-or-Dockerfile choice every other self-hosted platform still hands its users — and it's worth pricing exactly, because "no container config" turns out to mean something more specific than it sounds.
What Devpush Actually Removes From the Developer's Plate
Devpush (devpu.sh, MIT-licensed, ~4.7k GitHub stars) is a single web app — FastAPI backend, HTMX/Basecoat frontend, arq background workers, PostgreSQL, Redis, Traefik for TLS and routing, Loki for logs — all wired together with Docker Compose. Its creator, Ronan Berder, built it after getting frustrated trying to deploy Python apps with a Vercel-like experience; there wasn't a good option, so he wrote one.
The "no Dockerfile" claim is real but narrower than it sounds: Devpush ships a registry/ directory of stack presets — one per supported runtime — that get copied to the server at install time and can be overridden per-project. Push a Flask or Express app, and the matching preset generates the Docker build for you; you never see a Dockerfile unless you go looking for the preset that produced it. That's the same trick buildpacks and Nixpacks play — detection plus a generated build — just packaged as the platform's only path instead of one option among several.
Two things follow directly from that design:
- Language support is a fixed list, not an escape hatch. Today that list is Python (FastAPI, Flask, Django, and other frameworks) and Node.js, with PHP announced as coming soon. There's no Go, Rust, or Ruby preset yet, and — unlike a Dockerfile-or-buildpack platform, where an unsupported language just means writing your own Dockerfile — an unsupported language on Devpush means waiting for someone to write a new registry preset, or writing one yourself.
- Installation is a single curl-pipe-to-sudo-bash script on one box.
curl -fsSL https://install.devpu.sh | sudo bash, targeting Ubuntu 20.04+ or Debian 11+, with a Hetzner CPX31 as the documented reference target. The installer handles Docker setup, a dedicated system user, repo cloning, environment config, and systemd registration — genuinely less to type than provisioning Coolify or Dokploy by hand, and genuinely more trust extended to a script running as root on first contact than either of those tools' own install flows ask for.
What That Buys: A Real Time-to-First-Deploy
For the audience Devpush is actually built for — a solo developer or small team shipping a FastAPI or Flask app who doesn't want to think about containers at all — the loop is short: run the install script, connect a GitHub App, push to a branch, get a URL. Each branch and each configured environment gets its own subdomain automatically, which covers preview/staging URLs without extra setup. There's no Dockerfile to author, no docker-compose.yml to reason about, and no decision to make about which buildpack builder to point at — because there's only one path, and it's already chosen.
That's a genuinely different value proposition than Coolify or Dokploy, and Berder is explicit about the distinction: he built Devpush to compete with Vercel, Render, and Netlify's onboarding feel, not with Dokploy's Docker Swarm-orchestrated, container-first UI. "Dokploy and Coolify are more container-centric," he said on the project's Hacker News launch thread — Devpush is betting that most of its users would rather not think about containers as a concept at all, the same bet Vercel made for the JavaScript ecosystem years earlier.
Where the Bet Runs Out
The same narrowness that shortens time-to-first-deploy is exactly what forecloses the platform's growth path, and it shows up at three concrete points:
A language your app needs isn't on the list. A team standardized on Go for a couple of services, or wanting a Rust worker alongside a Python API, has no config-level workaround — Devpush's entire value proposition is that you don't write build config, so there's no "just add a Dockerfile" fallback the way there is on a Coolify or a Dokploy. The fix is a new registry preset, which is a project-level feature request, not a five-minute detour.
The app needs more than a web process. A Procfile-style multiple-process-type model (web + worker + cron) is the norm for anything non-trivial — Heroku standardized it over a decade ago, and every buildpack-based platform since has kept it. Devpush's docs describe configurable build and start commands per project, but the public documentation doesn't describe a first-class multi-process-type declaration comparable to a Procfile's web:/worker: split; a background job queue riding alongside the API is the kind of requirement that starts pushing a project past what a single generated build command was designed to express.
The deployment needs a second machine. Devpush's own install docs describe a single Ubuntu/Debian host end to end — there is no documented multi-node mode, no cluster of Devpush installs sharing state, no path to spreading a deployment across more than one box short of running two independent Devpush instances with no shared control plane between them. That's not a bug; it's the natural consequence of an installer that provisions one box's Docker daemon and stops. But it means the day a workload outgrows one Hetzner CPX31 — more replicas than one machine can host, or a requirement to isolate a noisy tenant onto separate hardware — Devpush has nowhere further to go without a rewrite of its core assumption, not a config change.
None of these are hypothetical edge cases for the platform's own target users; they're the three most common ways a solo project graduates into a team project. A tool this narrowly scoped will hit at least one of them within a year of real use.
HN's Reaction Is the Same Trust Bar Every Onboarding Script Has to Clear
Devpush's Hacker News launch thread is worth reading past the pitch, because the pushback landed on exactly the two seams above plus a third: trust in the install script itself. Commenters flagged the install method directly — "Supported on Ubuntu/Debian. No debs. Install: curl | sh" — the same objection security-conscious operators raise against any project's curl | bash onboarding, Devpush's included. Others compared it unfavorably to the incumbents on pure maturity: "Coolify.io is definitely more mature," one commenter wrote, while another said flatly, "I prefer Dokploy, Coolify sometimes has random bugs," and a third volunteered that they "always come back to CapRover, it's the platform I've had the less issues with." A fourth commenter took a swing at the stack choice itself, needling that a tool "supposed to automate typescript deployments" turned out to be "a bunch of python" — a fair jab, if a little unfair to a project that's explicit about being Python-first.
None of that reception is unique to Devpush. It's the standard bar every new self-hosted infrastructure tool clears or doesn't: does this thing I'm about to run as root, on a box holding my production data, come from a team with the track record to trust the install script blindly? Coolify and Dokploy earned their maturity reputation the slow way — years of production use, CVE disclosures patched in public, a large enough install base that "random bugs" is a specific, testable complaint rather than a guess. Any platform asking for root on day one — a Cluster API-based one included — has to clear the identical bar: publish what the installer actually does, keep the surface auditable, and let a track record substitute for blind trust rather than asking for it up front.
What a Cluster-API Fleet Gets For Free Instead
The place Devpush's architecture can't follow is exactly the place a Cluster API-managed fleet starts from by design. Where Devpush's installer provisions one Docker daemon and stops, Cluster API treats machine lifecycle as a first-class, declarative object from the outset — adding a node, whether it's the second machine or the fiftieth, is the same reconciled operation as the first, not a new deployment topology to invent. A workload that outgrows one box doesn't hit an architectural ceiling; it hits a scheduling decision the control plane was already built to make.
That doesn't make Devpush's bet wrong — for the solo Python developer it's built for, one box and no Dockerfile is a completely honest trade, and it's the right tool for that job today. It does mean the platform's own scope, read plainly against what it doesn't do yet, is the more useful signal than the "no Docker" headline: know which project you actually have before you pick the tool that assumes it'll stay small.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on a Cluster API-managed fleet of machines you own, from the first deploy to the fiftieth node. Star the repo on GitHub or deploy your first app today.
Sources
- Devpush homepage.
- hunvreus/devpush on GitHub.
- Devpush – Open-source and self-hostable alternative to Vercel, Render, Netlify | Hacker News.
- /dev/push: a self-hosted, open-source PaaS for git-based deployments.
- Self-Hosted Deployment Platform /dev/push Gains Traction as Developers Seek Vercel Alternatives — BigGo News.
