Navigate this article
Production infrastructure is more than the place where an application runs. It combines the controls needed to release, observe, update, and recover the system at a level of risk compatible with the business.
Architecture should be proportional to the product
Not every product needs Kubernetes, multiple regions, or dozens of services. Many applications operate better with a well configured VPS, containers, a protected database, a reverse proxy, and a clear update and recovery routine.
The decision considers criticality, volume, team, budget, availability requirements, and acceptable recovery time. Complexity is also an operational risk.
The right infrastructure is the smallest architecture that meets current requirements and provides an understandable path for growth.
I start with risk and the assets that need protection
Before configuring servers, I identify sensitive data, credentials, integrations, revenue flows, and points whose unavailability would interrupt operations. This map guides where stronger controls belong.
I also define responsibilities: who can deploy, access production, restore a backup, change DNS, or rotate a credential. Security without clear ownership tends to exist only on paper.
- Personal, financial, or strategic data.
- Credentials and integration keys.
- Domains, DNS, and certificates.
- Databases, files, and queues.
- Pipelines and artifact registries.
- Administrative access and audit trails.
Access, networking, and secrets form the first layer
I reduce exposed surfaces, separate internal and public services, and apply least privilege. Secrets remain outside source code, with limited scope and a viable rotation path.
Firewalls, TLS, and strong authentication help, but they do not replace updates, dependency inventories, and periodic access reviews.
- Restricted, individual, authenticated administrative access.
- Public ports only when necessary.
- Secrets outside repositories and capable of rotation.
- Encryption in transit and renewable certificates.
- Permissions separated by service and environment.
- Records of sensitive changes and access.
Deployment should be reproducible and reversible
A safe release produces the same artifact from the same version, applies migrations in a controlled way, and verifies health before exposing the new version. The pipeline should not depend on steps remembered by one person.
Rollback is not only reverting code. Database changes and API contracts need compatibility or their own recovery plan.
- Identifiable versions and reproducible builds.
- Configuration separated from code.
- Reviewed and compatible migrations.
- Health checks and post-deployment verification.
- Rollback or safe forward-fix strategy.
- A record of who deployed and what changed.
Observability shows what users are experiencing
Logs record events, metrics show trends, and traces follow an operation across components. What matters is connecting these signals to real questions: is the service responding, does the main flow complete, and are errors increasing?
Alerts should point to situations that require action. Too many notifications without priority only train the team to ignore them.
- Structured logs without unnecessary sensitive data.
- Availability, latency, error, and capacity metrics.
- Traces for distributed flows and integrations.
- Actionable alerts with owners and procedures.
- Dashboards connected to journeys and service objectives.
A backup exists only after restoration is tested
Databases, caches, and files have different life cycles. I define what must persist, for how long, where it is stored, and who can restore it. Important copies should not depend on the same server they protect.
The continuity plan records acceptable time and data loss, recovery order, and incident communication. It needs practice before it is needed.
- Retention policy and copies outside the primary environment.
- Tested restoration with evidence.
- RPO and RTO aligned with the business.
- Incident runbooks and clear ownership.
- Capacity and cost review over time.
Agents require additional execution boundaries
Agents can access data and execute tools, so the environment must control permissions, cost, time, volume, and possible effects. External inputs are treated as untrusted, and sensitive actions require approval.
Tracing, evaluations, and logs help explain how a decision was constructed. The harness should limit the impact of a wrong response and make behavior auditable.
- Tools exposed by function with minimum scope.
- Cost, time, and retry limits.
- Input and output validation.
- Human approval for irreversible actions.
- Auditing of calls, results, and failures.
- Safe interruption and recovery mechanisms.
Sources and further reading
This material presents my working approach and is educational. The right solution depends on the context, risks, and responsibilities of each project.
Share