# Localhost Works. Prod Doesn't. (One Command Fixes It)

> Prefilled .env.local for dev, .env.prod for the server. No dashboard spelunking or secret drift.

Source: https://boringpush.com/blog/localhost-to-vps

Production deployment usually descends into an agonizing afternoon.

Clicking through dashboards. Pasting API keys into input boxes. Realizing too late that your laptop, staging and production disagree on half their settings.

Keep two separate worlds instead. One for working on your laptop. One for the server.

## Local development: nothing to set up

Clone BoringPush and the local settings are already filled in.

A local SQLite database.

Test payment keys.

Localhost addresses.

Two development-only logins, one free user and one paying user.

Start the dev server and the whole stack runs on your laptop in seconds, with no cloud account.

Those logins and test keys exist only on your machine. They are switched off in production builds.

## Production: one file, synced once

The server gets its own settings file with real values. It is never committed to git.

It is separate from your local one, so test values cannot leak into production by accident.

Send it with `bp secret sync`. The command copies the file over SSH, locks down its permissions and reloads the app. No downtime.

Run it again whenever a secret changes.

## The five-point checklist

Before you point your live domain at the server, check five things.

1. **Your site address.** Your real domain, with `https://`. A wrong address is the usual cause of sign-in redirects going to the wrong place.
2. **The sign-in secret.** A long random value from a proper tool. Never reuse your local one.
3. **The payment provider.** Choose Stripe, LemonSqueezy or Dodo. Add the production product from that provider.
4. **The webhook signing secret.** Paste it from your payment dashboard and point the webhook at your domain.
5. **Your admin emails.** Enter your own. If the list is empty in production, nobody is an admin. That is the safe default.

Tick all five and most first-deploy surprises disappear.

## Common first-deploy mistakes

Four mistakes cause most of the pain.

The site address says localhost, or is missing `https://`. Sign-in redirects land in the wrong place.

The payment webhook still points at a test address. Paid orders never grant access.

The admin list is empty. You cannot reach your own admin pages.

And the Google sign-in callback was never registered for the live domain.

Each takes a minute to fix once you know where to look.

## A thirty-minute first deploy

Ten minutes on the settings file and the five checks.

Ten minutes to sync it and ship with `bp deploy`.

Ten minutes on a real test.

Sign in with a real account.

Place a test order.

Confirm access is granted.

If one step fails, stop and fix it. A half-right deploy is harder to debug than one that did not start.

## What happens when a setting is missing

BoringPush refuses to run degraded.

When a feature needs a secret that is not set, it stops with a clear message that names the missing setting. It does not run with empty credentials. It does not skip a check.

The message appears when the feature is used, not at startup. So a build can succeed without production secrets, and a real checkout without a payment key fails loudly.

A loud error on the first test order beats a silent failure on the first real one.

## Dev logins versus real accounts

Use the development logins to test paid features offline.

Sign in as the free user to see the paywall. Sign in as the paying user to see what customers get. That covers most of your testing without Google keys or email.

Before launch, sign in once with a real account on the production domain.

It proves the sign-in provider, the redirect address and the database in one move.

## Know this first

A missing setting stops the feature that needs it, with a clear message. It does not stop the build.

Test a real order before launch.

## Why BoringPush is the way to do this

Local and live, kept apart.

Your laptop has test logins and test keys. Your server has real settings. `bp secret sync` moves them over safely.

Test values never leak into production.

## FAQ

### How do I push my production settings to the server?

Run `bp secret sync`. It reads the server from your deploy remote, copies the file, locks its permissions and reloads the app. It works from anywhere you can reach the server over SSH.

### Do the development logins exist in production?

No. They are available only in development builds on your own machine.

### What if I forget a setting?

The first action that needs it stops with a message naming the missing setting. Fix the file, sync again and retry.

### Can I use a different production settings file name?

The kit looks for its standard production file in the project folder. Keep the standard name so the build, the start command and the sync all find it.

### Where do I keep a backup of my secrets?

In your password manager. The laptop file is the working copy and the server file is the live copy. Never keep secrets in chat or in git.

## Keep reading

- [Env Sync in 30 Seconds: Kill Secret Drift Forever](/blog/env-sync-production-nextjs) — the sync command in detail
- [Localhost to VPS in One Command? Almost](/blog/localhost-to-vps-one-command) — the whole last mile
- [Deploy Tonight: $5 VPS or Vercel (Pick in 60 Seconds)](/blog/deploying-boring) — choosing where to host