Preview deployments without Kubernetes

Shared staging is the typical default — not because it’s good, but because it’s familiar. One environment. Many branches. Constant “who broke it?” — while product and QA wait for a free slot to see a change that already exists in a pull request. That queue is a real bottleneck: feedback piles up behind a single box.

Frontend teams on big hosting platforms got spoiled: open a PR, get a URL, click around. Backend and mixed stacks often didn’t. The usual alternatives were “wait for staging” or “run ephemeral environments on Kubernetes.”

You don’t have to pick either. You can get open PR → live HTTPS URL → teardown without a Kubernetes platform — and that speeds up development by enabling faster, earlier reviews: bugs show up on the PR, not two QA deploys later. The wrong corner radius used to wait for a shared staging slot. With a preview URL, you catch it before merge.

If you want the basics first — what preview deployments are and why they matter — start with What is Beforeprod. This piece is the decision guide: which path fits.

What “good” looks like

A preview setup earns its keep when it does most of this:

• Isolated environment per PR or branch
• Shareable HTTPS URL for product, QA, and stakeholders
• Updates when you push
• Auto teardown on merge/close (or a clear TTL)
• Fits the CI you already run
• Works for more than a static frontend when you need it
• Ops cost you can explain to finance

If a path fails several of those, it’s a demo — not a workflow.

Four paths (no brand tour)

1. Shared staging (the typical default)

Best for: Tiny teams with almost no parallel work.

Reality: One box, many cooks. Feedback waits. Experiments collide. You learn late. Staging becomes the bottleneck for every parallel change.

One-liner: Cheap until it isn’t — then it taxes every sprint.

2. Frontend platform previews

Best for: Apps that already live entirely on a frontend-centric hosting platform.

Strengths: Near-zero config, PR-tied URLs, great developer experience for that stack. Frontend focus is a real advantage when the product fits.

Gaps: Strong vendor lock-in — previews are typically tied to a single framework / ecosystem and the platform’s model. They’re specialised for frontend (good when that’s enough; not enough when you also need an API, a worker, a Go service, or anything outside that lane). The “free” preview story stops covering you the moment the product is more than that frontend.

One-liner: Perfect when the whole product fits — incomplete (and sticky) when it doesn’t.

3. Kubernetes ephemeral environments

Best for: Teams that already run Kubernetes and want full multi-service previews.

Strengths: Real full-stack isolation and lifecycle control when the platform is already home.

Gaps: Even if you already operate a cluster, getting reliable per-PR previews right is still a lot of extra work — and if you don’t already run Kubernetes, you’re adopting a platform tax to solve a review problem. Powerful — and easy to overbuy.

One-liner: Right when K8s is home. Still hard work. Overkill when it isn’t.

4. DIY (CI + your cloud)

Best for: Strong platform engineering building specialised software so niche that a custom preview system actually pays for itself.

Strengths: Your accounts, your compose/helm/terraform, no vendor runtime.

Gaps: You own DNS, TLS, secrets, teardown bugs, and forgotten environments that keep billing. The first PR preview is a weekend. Keeping it reliable is a product. For most teams this simply isn’t feasible — it only makes sense when your stack and constraints are so specific that buying or adopting a shared path would cost more than building it yourself.

One-liner: Doable for niche platform teams — easy to underestimate, rarely worth it otherwise.

A simpler path: GitHub Actions → preview URL (no Kubernetes)

Beforeprod is built for teams who want the receipt — a real HTTPS preview on the pull request — without standing up Kubernetes or rewriting onto a frontend-only platform.

The point isn’t another environment for its own sake. It’s earlier reviews: product and QA click the same HTTPS link on the PR, catch issues sooner, and ship fixes faster — without waiting on the shared-staging bottleneck.

How it works in practice:

1. You keep your pipeline.
2. A GitHub Action builds the branch and talks to Beforeprod.
3. An isolated preview comes up; the HTTPS URL is written into the PR description.
4. Close the PR → the preview goes away.

Today we support Go and JavaScript (including Next.js). More stacks can land on the same Action path.

We’re in early access. The loop is real (deploy on open, cleanup on close). We’re onboarding carefully.

See it in public:

• preview-demo-go
• preview-demo-js

How to choose

Your situation	Lean toward
Whole app already on a frontend hosting platform	Stay on that platform’s previews
Multi-service and you already run Kubernetes	K8s ephemeral environments
Niche stack + strong platform team, custom cloud	DIY
On GitHub, hate shared staging, don’t want Kubernetes	Beforeprod-style Action → URL

Start this week

1. Pick one repo.
2. Wire PR open → deploy → URL on the PR → destroy on close.
3. Give one non-dev (PM or QA) the URL as the review surface for a sprint.

That’s the test: if feedback gets earlier, bugs show up on the PR instead of in QA, and staging fights drop — keep going.

FAQ

Do I need Kubernetes for preview deployments?
No. Kubernetes is one way to run ephemeral environments — not a requirement for a per-PR HTTPS URL. And even for teams already on K8s, preview plumbing is still non-trivial.

Preview vs staging?
Staging is usually shared and long-lived — the typical default, and often the bottleneck. A preview is short-lived and tied to a change (often a PR), then torn down.

What about databases?
Databases are definitely on our mind. If you already need one for a preview today, contact us — we’ll talk through what fits.

GitHub only?
Beforeprod’s public demos and Action path are GitHub Actions today (Go and JS). Say hello if you need something else.

Get early access

If you want preview URLs on your PRs without the Kubernetes tax, join the waitlist on beforeprod.com — or email info@beforeprod.com.

And if you want to see the receipt first, open the demos: preview-demo-go · preview-demo-js.

More context: About Beforeprod · What is Beforeprod