/dev/push

Self-hosted deployment platform, honestly reviewed. No marketing copy, just what you actually get when you run it yourself.

TL;DR

• What it is: Open-source (MIT) platform-as-a-service that gives you git-push deployments on your own server — the same UX as Vercel or Render, but everything runs on infrastructure you control [README].
• Who it’s for: Developers and small teams running Python, Node.js, PHP, or any Docker-able stack who are tired of Vercel’s per-seat pricing or Render’s free-tier spin-down behavior. Especially useful for non-JavaScript stacks that Vercel treats as second-class citizens [README][website].
• Cost savings: Vercel Pro runs $20/month per member. Render’s individual plan is $7/user with per-resource charges that add up. /dev/push runs on a single VPS — a Hetzner CPX31 (~$13/month) is the recommended starting point, and you deploy unlimited apps on it [README].
• Key strength: Polished UI and a genuinely simple deployment flow for something that’s entirely self-hosted. The install is a single curl command. Python, Node.js, PHP and anything else Docker can run works the same way, without the second-class treatment Python apps get on Vercel [README][website].
• Key weakness: GitHub-only at the moment — no GitLab or Bitbucket. Young project (4,572 stars) with a single primary maintainer. Not much third-party production war story coverage yet, which is either a good sign (it just works) or a yellow flag (not widely battle-tested) [README][website FAQ].

---

What is /dev/push

/dev/push is a self-hosted deployment platform. You connect it to a GitHub repository, configure your build and start commands, and from that point forward a git push triggers an automated build, zero-downtime rollout, and live URL — exactly like Vercel, but running on a server you own.

The GitHub README is direct about the pitch: “Like Vercel, but open source and for all languages.” [README] That’s unusually precise for an open-source project description, and it’s accurate. Vercel is effectively JavaScript-first — Next.js is a first-class citizen, Python apps work but feel bolted on, and the pricing model assumes you’re shipping web frontends, not backend services or API servers.

/dev/push is language-agnostic by design. The deployment model is Docker-based: you define a runner (a base image and some metadata), push your code, and the platform builds a container and routes traffic to it. The project ships a registry of default runners for common stacks — Python, Node.js, PHP — and you can add your own [README].

The project is built by Ronan Berder (@hunvreus), who describes it in the FAQ: “I went back to programming a little over a year ago. My first project was built with Next.js. I ended up being frustrated with the JavaScript ecosystem and switched to Python, but I still wanted to have an experience on par with Vercel.” [website FAQ] That origin story is the product brief. The tech stack underneath is FastAPI, HTMX, Basecoat, Docker Compose, Docker CLI, and Traefik as the reverse proxy [website FAQ].

---

Why people choose it

Without a substantial body of third-party reviews — /dev/push is early enough that detailed external write-ups are scarce — the case for it comes from the README, the website, and the problem it’s solving.

The Python problem. The most concrete and repeated pain point in the product’s own framing is the Python deployment gap. Vercel’s free tier supports Python serverless functions, but running a full Flask/Django/FastAPI application with persistent processes, workers, or a database on Vercel quickly becomes awkward or expensive. The demo on the /dev/push homepage shows a Flask app deploying with Gunicorn — that’s the product’s sweet spot [website]. If you’re building a Python backend and want Vercel-quality DX without Vercel’s JavaScript-centric architecture assumptions, this is the specific gap /dev/push targets.

The per-seat pricing problem. Vercel Pro is $20/member/month. A three-person team is $60/month before you’ve deployed a single thing. Render charges per resource, and its free tier spins down services after 15 minutes of inactivity — which is fine for a side project, brutal for a demo you’re showing a client. /dev/push is $0 on the software side; your only cost is the server. The Hetzner CPX31 (4 vCPU, 8GB RAM) runs under $15/month and can host multiple apps [README].

The ownership problem. When Render or Vercel changes pricing — and they have, multiple times — you’re negotiating from a position of dependency. With /dev/push, the software is MIT-licensed. You can fork it, modify it, run it forever on infrastructure you control. The vendor can’t raise your bill.

The maintainer’s credibility signal. The website FAQ lists sponsors including Jackson Lee (founder of FastHTML) and Sebastián Ramírez (creator of FastAPI) among people who backed the project. That’s a reasonable proxy for technical credibility in the Python web ecosystem [website].

---

Features

Based on the README and website:

Deployment core:

• Git-based deployments triggered by GitHub push [README]
• Zero-downtime rollouts — new container starts before old one stops [README][website]
• Instant rollback via the dashboard [README][website]
• Configurable build commands and start commands per deployment [website]
• Real-time, searchable build and runtime logs [README][website]
• Preview URLs for each deployment commit [website]
• Branch-based environment mapping (e.g., main → production, dev → staging) [README]

Environment management:

• Multiple named environments per project [README][website]
• Encrypted environment variables [README][website]
• Branch-to-environment mapping built in [README]

Infrastructure:

• Docker-based runners — anything that runs in a container works [README]
• Custom runner registry with overridable presets [README]
• Traefik for reverse proxying and routing [website FAQ]
• Custom domains with automatic Let’s Encrypt SSL [README][website]
• PostgreSQL and Redis available as services [merged profile]

Team features:

• Role-based access control (RBAC) with team invitations [README][website]
• Owner/Admin/Member roles visible in the dashboard [website scrape]

Platform:

• MIT license — self-host, fork, modify freely [README]
• Ubuntu 20.04+ and Debian 11+ supported [README]
• Online demo at devpu.sh (resets every hour) [website FAQ]
• SQLite database support listed as in-progress [website h2]

What’s missing or upcoming:

• GitLab and Bitbucket support not yet available [website FAQ]
• SQLite managed database appears to be on the roadmap but not shipped [website]
• No built-in CI test runner — deploy triggers on push, tests are your responsibility

---

Pricing: SaaS vs self-hosted math

/dev/push has no SaaS tier. It’s self-hosted only, MIT-licensed, $0 for the software.

Your only cost: the server.

The README recommends a Hetzner CPX31 — 4 shared vCPUs, 8GB RAM, 160GB SSD, €12.49/month (~$13.50 USD) [README]. That runs comfortably for multiple apps simultaneously. A leaner Hetzner CX22 (2 vCPU, 4GB) at ~$5.50/month works for a single app or a few small ones.

What you’re replacing:

Platform	Base cost	Notes
Vercel Pro	$20/member/mo	Per seat; 3-person team = $60/mo minimum
Render Individual	$7/user/mo + resources	Free tier spins down after 15 min inactivity
Railway Hobby	$5/mo + usage	Usage-based; can surprise at volume
/dev/push	$0 software + $5–15/mo VPS	Flat server cost, unlimited apps

Concrete example: A small team of 3 deploying 4 Python services on Vercel Pro, at $20/seat, pays $60/month just for the platform. On /dev/push with a Hetzner CPX31, that’s $13.50/month — all 4 services, no per-seat tax. Over a year: Vercel = $720, /dev/push = $162. Saving ~$550/year per small team, assuming one-time setup time of 2–3 hours.

The math gets more dramatic as team size grows or as you add more services, because /dev/push’s cost is effectively flat.

Caveat: these savings require you or someone on your team to manage the server. OS updates, backups, monitoring — you own those now. That’s not free, even if it’s not invoiced.

---

Deployment reality check

The install is a single command: curl -fsSL https://install.devpu.sh | sudo bash [README]. That’s genuinely unusual for a self-hosted PaaS — most competitors require multi-step docker-compose setup and manual configuration. /dev/push’s installer handles the stack setup.

What you need before you start:

1. A fresh Ubuntu 20.04+ or Debian 11+ server with SSH and sudo access [README]
2. DNS configured: A record for your app hostname, wildcard A record (*.example.com) for deployment subdomains [README]
3. A GitHub App created for repository access and login [README]
4. An email provider — either a Resend account (recommended) or SMTP credentials [README]

The GitHub App requirement is the most friction in the setup. You’re creating an app in GitHub Developer Settings, configuring callback URLs, noting the App ID and private key, and pasting it all into /var/lib/devpush/.env. For a developer this is 15 minutes. For a non-technical founder it’s a potential support call. The docs at devpu.sh/docs/guides/create-github-app exist for this reason [README].

What can go sideways:

• The project officially supports Ubuntu and Debian only. Other distros “may work but aren’t officially supported (yet)” [README]. If you’re on RHEL, Fedora, or Alpine, you’re on your own.
• The maintainer is a single primary contributor. There’s a Discord and GitHub issues, but support depth scales with one person’s availability.
• The GitHub-only integration is a hard limitation right now. If your team uses GitLab self-hosted or Bitbucket, you’re blocked [website FAQ].
• No native database provisioning yet beyond PostgreSQL and Redis listed as available features — SQLite as a managed offering appears to be in progress but not shipped [website, merged profile].

Realistic setup time for a developer: 45–90 minutes including server provisioning, DNS propagation wait, and GitHub App setup. For a non-technical person following the docs carefully: 3–4 hours, or a handoff to someone technical for the initial deploy.

---

Pros and cons

Pros

• Genuinely MIT-licensed. Not “source available,” not “fair-code with commercial restrictions.” MIT. You can run it, fork it, modify it, embed it in a product, and Ronan Berder cannot send you an invoice. [README]
• Single-command install. The curl | sudo bash installer is better than what most self-hosted PaaS projects ship. Competitors like Coolify and Caprover require more manual docker-compose juggling. [README]
• Language-agnostic. Python, Node.js, PHP, Go, Ruby — if it runs in Docker, it deploys the same way. No first/second-class distinction. [README][website]
• Zero-downtime deploys and instant rollback built in at the core, not bolted on as an enterprise feature. [README][website]
• Encrypted environment variables — not stored in plaintext in the config files. [README][website]
• Preview URLs per deployment. Every push gets a URL. This matters for showing clients or running QA before promoting to production. [website]
• Real-time, searchable logs — both build logs and runtime logs, live in the dashboard. [README][website]
• Technical credibility signals. FastAPI creator (Sebastián Ramírez) and FastHTML creator (Jackson Lee) are listed sponsors [website]. Built on FastAPI, HTMX, and Traefik — sensible, boring-in-a-good-way stack choices [website FAQ].

Cons

• GitHub-only. No GitLab, no Bitbucket. If your team uses anything else, you cannot use this today. [website FAQ]
• Single primary maintainer. 4,572 stars is a healthy number, but the project’s bus factor is 1. Longevity and support depth depend on one person. If Ronan moves on or loses interest, you’re forking. [GitHub]
• Ubuntu/Debian only officially. Other Linux distros are unsupported. [README]
• Limited ecosystem. No marketplace of add-ons, no managed databases beyond PostgreSQL/Redis, no built-in CDN, no edge functions. You’re getting deployment infrastructure, not a full-stack cloud platform. [README]
• No GitOps / infrastructure-as-code workflow. There’s no Terraform provider, no devpush.yaml spec file checked into your repo defining environments and deployment config. Configuration lives in the dashboard, not in version control.
• Young project. The GitHub repository shows last commit August 2025 based on website scrape data, and third-party production write-ups are scarce. Unknown failure modes, limited community knowledge base. [website scrape]
• Email provider required. Resend account or SMTP credentials are a prerequisite — not optional. If you don’t have an email setup, you need one before you can deploy. [README]
• SQLite as a managed service is listed on the homepage as “in the works” — it’s not shipped. Don’t plan around it. [website]

---

Who should use this / who shouldn’t

Use /dev/push if:

• You’re running Python backend applications and want Vercel-style DX without Vercel’s JavaScript-centric assumptions.
• You have a team paying $40–$100/month on Vercel or Render and you want that cost to become a flat server bill.
• You’re comfortable with basic Linux server administration, or you’ll pay someone once to set it up.
• You need MIT licensing — you want to fork, modify, or embed the deployment platform in your own product.
• GitHub is your version control platform.

Skip it if:

• Your team uses GitLab or Bitbucket. This is a hard blocker today.
• You need managed databases, CDN, edge functions, or serverless — /dev/push is a container deployment platform, not a full cloud. Stay on Render or Railway.
• You’re non-technical and have no one who can do the initial server setup. The curl | bash install is simple but DNS configuration and GitHub App creation require comfort with developer tooling.
• You need an SLA, enterprise support, or compliance certifications. None of those exist for a solo-maintained open-source project.
• Your stack is heavy on monorepo tooling, multiple build pipelines, or Turborepo/Nx — the platform’s strength is straightforward single-repo deployments.

---

Alternatives worth considering

• Coolify — The most feature-complete self-hosted PaaS. Supports Docker, Docker Compose, Nixpacks, Dockerfiles, databases, cron jobs, S3 backups. Also MIT-licensed. Steeper initial learning curve than /dev/push, but much broader feature surface. If you need managed databases, Coolify is the better fit.
• Caprover — Older, battle-tested, supports one-click app deployments from a marketplace. Less polished UI than /dev/push. Good if you need the app marketplace (WordPress, Ghost, etc.).
• Dokku — The granddaddy of self-hosted Heroku alternatives. Heroku-style git push dokku main deploys. Minimal UI, maximum extensibility via plugins. A good choice if you want maximum control and don’t need a dashboard.
• Render — The closest SaaS equivalent. Free tier is generous but spins down. Paid plans are usage-based. If you don’t want to manage a server, Render is the honest recommendation. But you’ll pay more at scale.
• Railway — Developer-focused PaaS with good Python support. Usage-based pricing that can surprise. No self-hosted option.
• Vercel — The UX benchmark for the category. Best choice if you’re shipping Next.js or other JavaScript frontends and the per-seat pricing is acceptable. Not the right tool for Python backend services.
• Fly.io — Good Python support, global edge deployment, free tier with limits. More infrastructure complexity in exchange for global reach.

For a developer or small team running Python or multi-language backend services, the honest shortlist is Coolify vs /dev/push. Pick /dev/push if simplicity and a minimal setup matter more than feature breadth. Pick Coolify if you need database management, more deployment types, or a larger community of production users.

---

Bottom line

/dev/push solves a specific, real problem: Python and non-JavaScript developers want the git-push deployment experience without paying Vercel per-seat rates or accepting Render’s free-tier limitations. The single-command install and clean UI make it one of the more approachable self-hosted PaaS options available, and the MIT license means you’re not betting on a vendor’s pricing decisions. The trade-offs are also real — GitHub-only, single maintainer, no managed databases, limited community knowledge base from being a young project. For a solo developer or small team running a few Python services, the math is obvious and the setup is manageable. For anything with serious uptime requirements, production-scale load, or compliance needs, the project isn’t there yet. Watch the GitHub stars and issue velocity over the next 12 months — if this gets traction, it will fill a gap that Coolify and Caprover haven’t quite closed for the simplicity-first crowd.

---

Sources

Primary sources (no substantive third-party reviews of /dev/push were available at time of writing):

1. GitHub Repository — hunvreus/devpush (README, architecture, install documentation). https://github.com/hunvreus/devpush
2. Official website — /dev/push (homepage, feature list, FAQ, demo). https://devpu.sh
3. Official documentation — Introduction, installation guide, guides. https://devpu.sh/docs
4. Hetzner Cloud CPX31 specs — recommended server for /dev/push deployment. https://www.hetzner.com/cloud