Platform

The platform layer does not exist yet. If you need production infrastructure today, use something else.

Why a platform layer exists at all

A framework without a runtime story eventually fails.

The failure mode is predictable. Code runs locally. It gets deployed somewhere. The "somewhere" introduces differences: environment variables that diverge, dependencies that resolve differently, secrets that leak or go missing, logs that exist only when you remember to add them. Over time, local behavior and production behavior drift apart. Debugging becomes archaeology.

The platform layer exists because alignment between code and runtime is a system property, not an operational task. If the framework does not define how code becomes a running system, something else will, and that something else will not share the framework's assumptions.

Putnami's position is that a framework that ignores deployment is incomplete. The platform is not a separate product. It is the continuation of the same constraints that define the framework.

Runtime invariants

These are properties Putnami considers non-negotiable in production. They are not features to be added later. They are constraints that any platform implementation must satisfy.

Every deployment is traceable to a revision

A running system must be attributable to a specific, immutable state in version control. There is no deployment without a revision. There is no revision without a reviewable change. If you cannot answer "what is running and why," the system is not deployable.

Environments are derivable from code

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.

Runtime behavior is observable by default

A system that does not emit structured signals about its behavior is not operable. Observability is not a layer you add when you have time. It is a property the runtime enforces. If code runs without producing traces, logs, or metrics, the platform considers that a failure.

Security boundaries are enforced, not suggested

Defaults are secure. Unsafe paths require explicit acknowledgment. The platform does not trust application code to enforce its own boundaries. Secrets are never logged. Authentication is not optional. The system fails closed.

Data ownership remains with the operator

The platform does not own application data. It does not require proprietary storage. Schemas are versioned, portable, and inspectable without vendor mediation. If you cannot export your data and leave, you do not own it.

Automation and humans follow the same rules

There is no distinction between a deployment triggered by a human and one triggered by a script or an AI agent. The same validation, the same guardrails, the same audit trail. Automation is not a backdoor.

Scope boundaries

The platform is responsible for:

Compute: Running application code in isolated, versioned containers.
Delivery: Building, deploying, and promoting revisions across environments.
Configuration: Managing environment-specific values and secrets.
Observability: Collecting and exposing structured runtime signals.
Networking: Routing traffic, issuing certificates, enforcing access control.

The platform is not responsible for:

Application logic: The platform does not dictate how you write code. It runs what you build.
Data storage internals: The platform may provision databases, but it does not own your schema, your queries, or your data. You do.
Third-party integrations: The platform does not abstract away external services. If you use Stripe, you integrate with Stripe. The platform provides configuration and secrets management, not SDKs.
Cost optimization: The platform does not automatically scale to zero, right-size instances, or negotiate your cloud bill. Resource allocation is explicit and reviewable.
Magic: There is no inference, no auto-detection, no "just works." The platform does what it is told, and what it is told is defined in version control.

Expected direction

The platform is expected to eventually handle:

Multi-region deployment with explicit traffic policies
Managed PostgreSQL and Redis provisioned per environment
Preview environments derived from branches
Background job scheduling and execution
Blob storage with access control
Centralized log aggregation and trace correlation
Alerting based on declared SLOs

These capabilities may arrive incrementally, partially, or not at all. The order is not fixed. The scope may narrow if constraints cannot be satisfied.

What will not change is the structural relationship: the platform serves the framework, the framework serves the workspace, and the workspace is defined in code.

Current status

The framework is usable today. The platform is not.

You can build applications with Putnami, run them locally, and deploy them to your own infrastructure using standard tools. The platform layer will eventually provide a more integrated path, but it is not required to benefit from the framework.

If you are evaluating Putnami, evaluate the framework. The platform is intent, not product.

Where to go from here

The framework is ready for real work. Start building:

Getting started — a running app in under 3 minutes
How-To guides — build a web app, an API, add persistence, authentication, and more
Samples — 13 runnable projects from hello-world to a full-stack app