Make the deployable artifact identifiable
An immutable deployment approach replaces an application artifact or compute unit rather than editing it in place. The aim is repeatable delivery and a clear relationship between reviewed source, built artifact and running workload.
That does not mean every network setting or database must be destroyed and recreated for every change. Infrastructure tools can update some resources in place, while application data remains intentionally mutable.
Reproducibility needs more than a lockfile
Pin the inputs that matter: dependency resolution, base image digest, build tools and relevant configuration. Build once and promote the resulting artifact through environments where practical.
A multi-stage image can reduce runtime contents, but copying native modules between incompatible build and runtime environments can break them. Validate architecture, C library and runtime compatibility rather than assuming all Linux images are interchangeable.
A minimal or distroless image reduces available utilities. It does not make an exploited application unable to download data, write files or perform harmful actions through its runtime. Use appropriate permissions, a read-only root filesystem where supported and narrowly scoped writable volumes.
Signing establishes a specific claim
A signature can bind an artifact to a trusted signing identity or key. An SBOM records components according to the generator's scope. Neither proves that the software is free of vulnerabilities.
Cosign documents distinct ways to sign artifacts and associate attestations or SBOM information. Attaching a file and signing an image are different operations; the verifier must check the intended subject and trusted identity. Cosign signing and attestations.
For admission enforcement, test allowed, unsigned, incorrectly signed and unavailable-verification cases. A policy file in a repository is not proof that all workloads are covered by a running admission controller.
Infrastructure state needs protection
Terraform state supports management of real resources; it is not the desired configuration itself. Protect it with access controls, versioning and the backend's supported locking mechanism.
The current S3 backend supports use_lockfile. Its documentation marks DynamoDB-based locking as deprecated and describes migration considerations. Match the configuration to the Terraform versions used by every writer. S3 backend locking.
Locking coordinates state operations. It does not prevent every console edit or establish zero drift. Detection and a deliberate reconciliation process remain necessary.
Node replacement can disrupt work
Karpenter supports disruption mechanisms including expiration. Its documentation explains draining behavior, disruption constraints and the relationship between expireAfter and terminationGracePeriod. Karpenter disruption.
A configured lifetime is not proof that replacement is seamless. Test Pod disruption budgets, shutdown, persistent volumes, image availability and capacity shortages. Ensure that every scheduled architecture has a compatible image and native dependencies.
Rollback has a data boundary
Reusing a previous image can restore application code, but the old version may not understand a new schema or newly written data. Reverting an infrastructure change can also propose destructive operations.
Keep schema changes compatible where possible, retain tested artifacts and rehearse recovery under representative conditions. Verify both service health and domain correctness.
The related Silsila pipeline and Terraform infrastructure are portfolio reference implementations. Their source illustrates deployment ideas; this article does not claim measured production recovery, complete policy coverage or a universal zero-downtime result.
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
