A system for keeping code and production aligned

The recurring failure mode

Code runs locally. It gets deployed somewhere. The "somewhere" introduces differences.

Environment variables diverge between machines. Dependencies resolve differently across environments. Secrets leak or go missing. Logs exist only when someone remembers to add them. Configuration accumulates in places that are not version control. Over time, local behavior and production behavior drift apart.

Most teams recognize this drift and respond with discipline: checklists, runbooks, infrastructure-as-code, observability retrofits, deployment pipelines with manual gates. These interventions work until they don't. The discipline required to keep systems aligned grows faster than the team's capacity to maintain it.

The failure is not incompetence. It is structural. When the system that runs code is disconnected from the system that writes code, alignment becomes a process problem. Process problems scale with team size, codebase age, and operational complexity. Eventually, debugging becomes archaeology. Changes become risky not because they are complex, but because no one can confidently describe what is running and why.

This pattern repeats across organizations regardless of talent, tooling, or investment. The underlying cause is the same: alignment between code and runtime is treated as an operational task rather than a system property.

The Putnami bet

Putnami is built on a specific assumption: alignment is a system property, not a process.

Conventions fail because they depend on enforcement. Runbooks fail because they depend on memory. Checklists fail because they depend on discipline. Any approach that requires humans to consistently perform alignment work will eventually produce drift. The question is when, not whether.

If alignment must be guaranteed, it must be structural. The system that defines code must also define how that code becomes a running system. The constraints that apply locally must also apply in production. The configuration that exists in one environment must be derivable from the same source as every other environment.

Putnami is a response to this constraint, not a tool assembled from convenient parts. The framework, the tooling, and the eventual platform layer share the same assumptions because they were designed together. This is not a claim of superiority. It is a statement of intent: Putnami prioritizes structural alignment over flexibility, and accepts the tradeoffs that follow.

A framework that ignores deployment is incomplete. Putnami's position is that the runtime story is not a separate concern to be addressed later. It is the continuation of the same constraints that define the framework itself.

How the system evolves over time

A system built with Putnami follows a linear path from local development to production operation. This path is not a tutorial or a feature list. It is a description of invariants that become necessary as systems grow.

At the beginning, a developer works locally. The framework enforces conventions: where code lives, how dependencies are declared, how configuration is accessed. These conventions are not suggestions. They are constraints that the tooling validates.

As the system grows, it requires collaboration. Multiple developers work in the same codebase. The workspace structure ensures that changes are isolated, dependencies are explicit, and builds are reproducible. What worked for one developer continues to work for many because the constraints did not change.

When the system is ready for deployment, the same constraints apply. An environment is not a place. It is a function of configuration and code. Local, preview, and production are the same system with different inputs. If an environment cannot be reproduced from its definition, it is not an environment. It is an accident.

In production, observability is not optional. A system that does not emit structured signals about its behavior is not operable. Security boundaries are enforced, not suggested. Data ownership remains with the operator. Automation and humans follow the same rules.

None of these properties are added later. They are present from the beginning or they are absent entirely. The framework does not permit a gradual transition from undisciplined to disciplined. It starts disciplined or it does not start at all.

What exists today vs what is intent

Three layers compose the full system. They exist in different states of readiness.

Framework: Usable today. The core libraries, the application model, the workspace structure, the configuration system. You can build applications with Putnami now, run them locally, and deploy them to your own infrastructure using standard tools.

Tooling: Evolving. The CLI, the build system, the test runner, the development workflow. These tools work but continue to change as the framework matures. Stability is a goal, not a guarantee.

Platform: Future intent. The managed runtime, the deployment system, the observability infrastructure, the operational layer. This does not exist yet. If you need production infrastructure today, use something else.

The platform layer is designed to be optional. Putnami does not require managed infrastructure to function. The framework stands alone. The platform, when it exists, will provide a more integrated path for teams who want it. Teams who prefer to manage their own infrastructure will continue to do so.

The platform is not a separate product. It is the continuation of the same constraints that define the framework. But continuation is not completion. The platform may arrive incrementally, partially, or not at all. The scope may narrow if constraints cannot be satisfied.

Who Putnami is for

Putnami is for teams who believe:

• Production systems should be derivable from version control.
• Observability is a system property, not a debugging afterthought.
• Security defaults should be strict, not permissive.
• Automation should follow the same rules as humans.
• Data ownership is not negotiable.
• Structural correctness is worth the cost of reduced flexibility.

If these beliefs align with yours, the framework is available now. The platform is not. Waiting for the platform to mature is reasonable. Contributing to its direction is welcome. Using the framework without the platform is intended.

Who Putnami is not for

Putnami is not for teams who need:

• Production infrastructure today. The platform does not exist yet. The framework requires you to handle deployment yourself.
• Maximum flexibility. Putnami is opinionated. If you want to choose your own adventure at every layer, this is not the right system.
• Serverless scale-to-zero economics. The platform, when it exists, will not optimize for idle cost. It will optimize for predictability.
• Vendor-managed everything. Data ownership means operational responsibility. If you want to delegate storage, secrets, and compliance entirely, look elsewhere.
• Immediate results without understanding. The system prioritizes structural correctness over convenience. If you want fast results without learning the constraints, this will frustrate you.

Opting out is not a failure. It is a recognition that different systems serve different needs. If Putnami's constraints do not match your constraints, using something else is the correct choice.