Why we built around a single plain-text file

When you sign up for most deployment platforms, the first thing they ask you to do is learn something. A new dashboard. A new CLI. A set of environment panels, billing screens, and config tabs that are different on every platform and live entirely outside your project.

That is fine when things are working. It is frustrating when they are not, and it is a real problem when you want to move. All of that configuration is locked up in someone else's database. Your code is portable. Your deployment setup is not.

What does an app actually need to go live?

We kept asking this question and the answer was always the same short list. A domain. A cloud provider and region. The names of any secrets it needs at runtime. A sense of how it should scale. Maybe a health check path. That is more or less it.

None of those things are complicated. None of them are dynamic. They do not change from deploy to deploy. And yet every platform we looked at expected you to configure them through a UI that did not travel with your code.

Configuration that lives with the code

Your project already knows how to describe itself. There is a README that explains what it does. A package.json or requirements.txt that lists what it depends on. A Dockerfile if it has specific runtime needs. These files travel with the code because they belong with the code.

PRODUCTION.md is the same idea applied to deployment. It is a plain-text file that answers the questions a hosting platform needs answered: where should this run, what does it need, and how should it behave when traffic arrives. You add it to your repository once and it stays there, version-controlled alongside everything else.

It is a standard, not a Prodwise feature

We want to be clear about this. PRODUCTION.md is an open standard. The format is publicly documented at production.md. Any platform can read it. Any developer can write one. We built Prodwise to support it because we think it is the right model, not because we invented it.

The goal is a world where your deployment configuration is as portable as your code. Where switching providers is a matter of pointing a different tool at the same file, not re-entering everything from scratch.

What that looks like in practice

A typical PRODUCTION.md takes about two minutes to fill in. You write your domain, pick a cloud and a region, list the names of any environment variables your app reads, and specify whether it should scale automatically. That last part matters: you are not hard-coding resource limits, you are expressing intent.

Once it is in your repository, you connect GitHub to Prodwise and we handle the rest. The file tells us what to build. We build it. When you push a change, your live site updates automatically. When you add a new secret, you add the name to the file and supply the value to us once. After that it is injected at runtime and you do not have to think about it again.

If you want to try it, the quickest way is to connect a GitHub project and add a PRODUCTION.md. We give you a template that covers the common cases.