The Twelve-Factor App in 2026

Part 1 of a series. Part 2: how the twelve factors shape the way we design Recipes.

Building modern apps is hard. How do you prevent your backend from bricking the moment you get a spike in users? How do you keep your local, dev, and prod environments aligned? How do you keep your secrets safe (and out of your public GitHub repo!)?

In 2011, Adam Wiggins outlined The Twelve-Factor App: a methodology meant for any developer building apps that run as a service. SaaS, PaaS, IaaS, it doesn’t matter—you should be using this methodology. It looks like this:

1. One codebase per app

Track each app with version control (git) in its own repository. If multiple apps share code, that’s a problem; instead, factor the code into a library and import it via your dependency manager.

2. Declare and isolate dependencies

Never ever ever ever rely on the implicit existence of packages. Declare all packages so future you or other team members, or containers can import the dependencies.

3. Separate config from code

Basically store keys in .env, AWS Secrets Manager, or really anything other than in your index.ts file. Not only do these vary between deployments, but some are private and could lead to disastrous results.

4. Backing services = attached resource

What’s that mean? Basically take everything like databases, storage buckets, notification systems, queueing systems, etc. and treat them ALL as third-party resources. S3, RDS, SQS, SNS, they’re not part of the production deploy, but attached.

5. Build -> Release -> Run

They should be separate stages.

Build stage: turn your code into an executable

Release: combine that with config (from earlier!) and give it’s own unique id

Run: it’s immutable from here

6. Stateless Processes

Your app will be one or more processes that share nothing. No durable state in process memory. All meaningful information should be in the database.

7. Ports baby!

Your app should be exposed through ports. Just like how you route to localhost:3000 in development, your production app should have a routing layer that directs HTTP traffic to a port-bound address.

8. Scale with more processes

Remember how we said your app should be made of one or more stateless processes? Here’s why it’s important. When you need to handle more demand, just spin up more processes! This is why we love the cloud.

9. Fast startups, clean shutdowns

What goes up must come down. Now that you have a lot of processes handling your millions of users, remember: the processes are disposable. They’re already stateless, now just make sure they can stop at any moment.

On the flip side, make sure they can start in just a few seconds.

10. Dev, Staging, Prod

This is super important if you’re a fast-moving product team. The goal is to make the time between development and deployment as short as possible.

Keep the gap between dev and prod small to allow continuous deployment.

• Write code and push it within hours, not days
• The one who writes the code should see deployment details
• Keep dev and prod stacks similar

11. Logs: Processes’ responsibility

The app should never be worried about logs because the processes should be writing their own event streams. Watch realtime via a console.

12. Admin Processes

Admin tasks are one-off processes in an identical environment to the release.

Conclusion

Follow these twelve rules to build modern apps that scale, allow for continuous deployment, are portable, and are built for cloud platforms.