Start Here

Find the next guide for your task

The homepage shows recent articles. This page helps you find a starting point when the question you need to answer is more specific: how to provision a platform, promote a release, control access, or operate a service reliably.

How these guides are produced: DevOpsDreams articles are primarily based on vendor and project documentation. They add technical explanation, trade-offs, diagnostics and reference examples. They do not represent a DevOpsDreams lab or production deployment unless a specific article provides evidence of that work. Example values and illustrative calculations are not measured production results. Any locally verified tool behavior is identified separately from cloud or cluster testing.

Choose one route below. Each gives you a first guide, useful follow-up reading, and something concrete to produce. You do not need to read every article or follow publication order.

Choose a route

Your current task	Start with	Work towards
Build or reorganise an EKS platform	Terraform reference architecture	A map of resource ownership and change boundaries
Deploy and promote application changes	Argo CD auto-sync and health checks	A promotion process with a defined rollback path
Design private access or tenant isolation	Private EKS clusters and ingress	An access matrix for users, workloads, and tenants
Set reliability targets or improve incident response	SRE error budgets on EKS	A service objective and response decisions tied to user impact
Understand resource costs or resize workloads	Kubernetes cost visibility	A resource decision supported by usage and allocation evidence

1. Provision infrastructure with clear ownership

Use the Terraform reference architecture for EKS to identify the boundaries between cloud infrastructure, cluster configuration, and application delivery.

Then choose the guide that addresses your next decision:

• Designing Terraform modules: decide which inputs and outputs a platform module should expose.
• State, locking, and backups: plan state access, concurrent changes, and recovery.
• Terraform CI/CD with GitHub Actions: connect review and execution to those boundaries.

Practical outcome: write down which repository and tool own each resource, who approves a change, and how state can be recovered.

2. Deploy and promote application changes

Start with Argo CD auto-sync and health checks to understand reconciliation and health reporting. Continue with environment promotion strategies when choosing how a reviewed application version moves between environments.

If you need canary or blue-green releases, read Argo CD and Argo Rollouts. Use it to separate the responsibilities of applying desired state, controlling a rollout, and evaluating release signals.

Practical outcome: define what triggers promotion, which version is deployed, what stops a release, and what rollback can and cannot reverse, including database changes.

3. Design traffic and tenant boundaries

Start with private EKS clusters and ingress patterns to distinguish Kubernetes API access from application traffic. Use Gateway API and Ingress when comparing routing responsibilities.

For shared clusters, read multi-tenant GitOps with Argo CD alongside namespace and NetworkPolicy isolation. They address different parts of the access boundary.

Practical outcome: list who can change each resource, which workloads can reach each service, and which identities can authenticate. Validate that matrix in a representative environment.

4. Improve reliability and incident response

Start with SRE error budgets on EKS to connect service objectives, user-facing indicators, burn-rate alerts, and release decisions.

Then read Kubernetes and EKS incident response to organise evidence collection, containment, and recovery decisions.

Practical outcome: define one service objective, name the response owner, and write down the evidence needed to continue, pause, or roll back a release.

5. Make resource and cost decisions

Start with Kubernetes cost visibility with OpenCost to connect resource usage with cost-allocation questions.

If your next question is how to change a running Pod's resources, read in-place Pod resource updates. Check the stated version requirements and constraints before choosing this approach.

Practical outcome: identify the workload and resource involved, explain the evidence for a change, and define how you will check its effect on performance and reliability.

New to the blog?

Pick one familiar workload and follow it through three questions: who provisions its infrastructure, how a new version reaches users, and how you know it is working. Routes 1, 2, and 4 provide a suggested reading sequence. Start with the question you can answer least confidently.

These paths organise the blog's technical guides; they are not a complete beginner course. If you already know your subject, use the header search or the homepage topic links to find an article directly.

Before using an example

Match its assumptions to your software versions, permissions, network configuration, and workload requirements. Check linked upstream documentation and test changes in a representative environment. Reference designs are starting points, and an article does not establish that an example has been executed in your system.

See About for the blog's scope and the Editorial Policy for how to interpret examples and sources. Use Contact to report an error or suggest a missing guide. The Privacy Policy explains the site's contact, comment, analytics, and advertising features.

Try the allocation worksheet: Compare team allocations with equal or proportional sharing, keep idle capacity separate, and download the calculation. The worksheet uses your inputs and does not connect to your cluster or AWS billing.