# Luck Goes to Cloud - Complete Documentation

This file contains all documentation concatenated into a single file for easy consumption by LLMs.

> Sobre arquitetura, cloud, devops, desenvolvimento e os processos do que eu construo no meu dia a dia.

## Table of Contents

This document includes all content from this project.
Each section is separated by a horizontal rule (---) for easy parsing.

---

# Redirecting to: /en/about

URL: https://blog.luckramos.com/about

Redirecting to: /en/about [Redirecting from /about/ to /en/about](/en/about)

---

# 404 · signal lost · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/404

> The page you tried to reach is not in the archive. The signal got lost between the terminal and the cloud.

── ERR · 404 · NOT_IN_INDEX

## 404

The page you tried to reach is not in the archive. The signal got lost between the terminal and the cloud.

[BACK TO HOME →](/en) [BROWSE THE ARCHIVE](/en/posts)

---

# /about · who am I? · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/about

> Who runs Luck Goes to Cloud and how to reach me.

$ whoami --verbose --since=2026

/about · the colophon · {aboutIssue}

--> Hi! I'm Lucas Henrique Ramos, but most people know me as Luck (/luki/) — brazilian tech lead, devops and full-time problem solver. I work at UEEK and write here about my processes, decisions, problems, and the solutions I find while building and scaling software.

I've been working in tech since 2019, and I've been through plenty of projects, clients, and truly bizarre hacks. I've also been the one responsible for a good chunk of those hacks, and I honestly believe that screwing up it's one of the best ways to learn. Outside of work I'm a complete fanatic for music (the blog's name is a nod to the Descendents' Milo Goes to College), fashion, art, and tattoos. Hope you find something cool around here!

[BROWSE THE POSTS →](/en/posts) [SAY HELLO](mailto:lukcramos@gmail.com)

── §02 · CHANNELS

## Where to find me

[01 $ git clone @luckramos ↗](https://github.com/luckramos)

[02 $ curl -L in/lukcramos ↗](https://www.linkedin.com/in/lukcramos)

[03 $ ssh -p 443 @lukcramos ↗](https://x.com/lukcramos)

[04 $ curl -L UEEK ↗](https://ueek.digital)

[05 $ echo | sendmail lukcramos@gmail.com ↗](mailto:lukcramos@gmail.com)

[06 $ tail -f /en/rss.xml ↗](/en/rss.xml)

── §03 · COLOPHON

## How is the blog made?

typeface (display)

Space Grotesk

typeface (mono)

JetBrains Mono

accent (dark)

#00FF41 · phosphor P1

accent (light)

#CC5500 · phosphor P3

built with

Astro · React · MDX

Found a typo? A logic error? A take you'd argue with at the bar? [Tell me](mailto:lukcramos@gmail.com)

---

# Luck Goes to Cloud

URL: https://blog.luckramos.com/en

> Architecture, cloud and devops in practice — starting from the questions and problems I run into day to day, and my process as I try to solve each one.

VOL. I · NO. 01 MMXXVI · GENESIS

FEATURED · INFRASTRUCTURE ·
01.04

## luck:*goes*:cloud.

My notes *on architecture, cloud and devops, the problems I run into and the process behind what I build in my ***day to day.**

[BROWSE THE POSTS→](/en/posts) [READ THE LATEST](/en/posts/structuring-iac-multi-environment) 2 posts · est. ∞

[01.06 · INFRASTRUCTURE How to structure a Pulumi IaC project for multiple environments](/en/posts/structuring-iac-multi-environment)

[01.07 · DEVOPS Why we need a staging environment](/en/posts/why-we-need-a-staging-environment)

.:=++***+=:.
-#@@@@@@@@@@@@@@@@#-
:%@@@@@@@@@%%%%%%%@@@@@@%-
-@@@@@@@@@%%%%%%%%%%%%%%@@@@@=
@@@@@@@@%%%%%%%%%%%%%%%%%%%%@@@@:
.@@@@@@@@@@%%%%%%%%%%%%%%@@@@@@@%%@=
.@@@@@%###@@@@@%%%%%%%%@@@@%**#%@@@@@+
@@#- =@@@@@@@@@@- -*%@-
. *%%@@@@%= *@@@@@@- +%@@@@@*:
=@@@@*. =#@@- +@@#- .+@@@@
@ %#@@ @@ @@ -- -@% @@ @@@% .@+
.@- %@@@ *@ @@@@ -@+ @@@# +@*
.@@ @@@* -@* :@@@@. %@- *@@@ %@*
.@@% +@@@@%%@@- :@@@@@@. -@@%%@@@@+ %%@*
@@@@- :-=- *@@@%%@@@* :--: -%##%*
#@%%@@@#=-::-+%@@@@@@@@@@@@%*--:-=*%%%%*#%
@@%%%%%@@@@@@@@@@@: .@%@@@@@@@@%%%#**%@:
@@@%%%%%%%%%%%%%%%@=------=%%%%%%%%%%%%%#*#%@@=
@@%%%#%%%%%%%%%%%%%%@@@@@@@@%%%%%%%%%%%%%#*#@@@@+
@@@@%#*%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%####%#**%@@@@:
*@@@@#++%%%%%%%%%%%%%%%%%%%%%%%%#%%%######%#=+#@@@@@
-@@@%==*%%%%%%%%%%%%%%%%%%#%%#####%%#%%###%#*=+*@@@%
:. #%%%%%%%%%%%%%%%%%%%#%%%%%%##%%#####%#*#: .-:
@@%%%%%*#%%%%%%%%%%%#%%#####%%#+*#%%%**%-
@@%%#%#**#%%####%%%%%%%#####%%***#%%%**@:
#@%%%%#*##%%%%%%%%%##%%%%##%%#****%%#*#@
=@%%%%#%%%%%%%%%%%*####%%%%%%##%%###**#%
@@@@@#:.=@@%%%%%%%**#%%%%%%%%*-:+%%#%@+
#%%+ %@@@@@* =%@%%%%- :#%%=
:+*+: =*+-

FIG.01 · 「ghost」

722 frames @ 30fps

render · ascii · 130×38

loop · 24.1s/cycle

---

# DevOps · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/category/DevOps

> Posts in the DevOps category on Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## DevOps · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:cat:devops clear all

[FEATURED · 01.04 ● DEVOPS Jun 24, 2026 5 min Why we need a staging environment Does keeping a replica of the productio](/en/posts/why-we-need-a-staging-environment)

per page122436100

---

# Infrastructure · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/category/Infrastructure

> Posts in the Infrastructure category on Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## Infrastructure · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:cat:infrastructure clear all

[FEATURED · 01.04 ● INFRASTRUCTURE Jul 01, 2026 4 min How to structure a Pulumi IaC project for multiple environments M](/en/posts/structuring-iac-multi-environment)

per page122436100

---

# /blog · the index · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts

> The complete list of posts on Luck Goes to Cloud — notes on architecture, cloud, system design and building systems.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 2

showing 1–2 of 2

updated 19:47 UTC

active filters:none

[FEATURED · 01.04 ● INFRASTRUCTURE Jul 01, 2026 4 min How to structure a Pulumi IaC project for multiple environments M](/en/posts/structuring-iac-multi-environment)

[DEVOPS 01.05 Why we need a staging environment Luck Ramos Jun 24, 2026 · 5 min](/en/posts/why-we-need-a-staging-environment)

per page122436100

---

# How to structure a Pulumi IaC project for multiple environments · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/structuring-iac-multi-environment

> Multiple environments and how to structure them in a single reproducible project

[← back to /blog](/en/posts)

##### ── META

cat: **infrastructure****
read: 4 min

words: 897

date: 2026-07-01

issue: 01.04**

##### ── AUTHOR

*

Luck Ramos

Tech Lead

##### ── SHARE

[↗ x.com](https://x.com/intent/tweet?text=How%20to%20structure%20a%20Pulumi%20IaC%20project%20for%20multiple%20environments&url=https%3A%2F%2Fblog.luckramos.com%2Fen%2Fposts%2Fstructuring-iac-multi-environment%2F) [↗ hn](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fblog.luckramos.com%2Fen%2Fposts%2Fstructuring-iac-multi-environment%2F&t=How%20to%20structure%20a%20Pulumi%20IaC%20project%20for%20multiple%20environments) [↗ email](mailto:?subject=How%20to%20structure%20a%20Pulumi%20IaC%20project%20for%20multiple%20environments&body=https%3A%2F%2Fblog.luckramos.com%2Fen%2Fposts%2Fstructuring-iac-multi-environment%2F)

##### ── FILED UNDER

[#iac](/en/posts/tag/iac)[#pulumi](/en/posts/tag/pulumi)[#terraform](/en/posts/tag/terraform)[#aws](/en/posts/tag/aws)[#devops](/en/posts/tag/devops)[#environments](/en/posts/tag/environments)

● INFRASTRUCTURE 01.04 Jul 01, 2026 4 min

## How to structure a Pulumi IaC project for multiple environments

Multiple environments and how to structure them in a single reproducible project

FIG.1 · IaC diagram

I’d say undeniably one of the main things when we start studying infrastructure, cloud, devops and so on is IaC. Code versioning has always been considered one of the cores of software development. It’s indisputable that the overwhelming majority of the software out in the market today has a git repository behind it, and all that just so we can blame* some hack from 6 months ago and find out we were the ones who wrote it.

**Infrastructure as Code** comes precisely to bring all the goodness of VCS to our environment building, and it reinforces essential practices like reproducibility. In this post I want to walk through how to structure your infrastructure as code to support multiple environments.

## Why multiple environments?

Software is something predictably unpredictable, so much so that one of the most famous disciplines we have is **chaos engineering**, created precisely to try to guarantee as much resilience as possible in those unpredictable, random, chaotic situations. One of the processes within quality assurance is testing features and deliverables across multiple environments before production.

**Dev**: The environment where the developer works is commonly referred to as the **dev/develop/development** environment. It can be local, cloud, virtualized, a VPS, a WSL, whatever; it’s the environment where our developer builds and tweaks things from scratch.

**QA**: This is usually where the QA team tests the feature and its end-to-end integration in an isolated, secure environment. The client has no access; it’s internal.

**Staging**: Very similar to the QA environment, but with the caveat that the idea here is for it to be an exact replica of the production environment. Very useful for stress testing and capacity planning.

**Production**: The final environment, where clients access.

The idea behind the flow is to always promote a feature across these environments. It’s common to find flows where there’s only a QA environment and no staging, or only a staging that doubles as QA, or the ones that have none of it and test straight in production, praying nothing breaks.

## IaC structure to support multiple environments

I’ll use **Pulumi** here for the example, but all the concepts discussed here can be applied to other tools like **Terraform**.

One of the most widespread concepts here is that a **stack** *(a workspace in Terraform’s case)* always maps to one **environment**. Consider the following.

We added a new endpoint to our API and we need to validate that it works end-to-end in a **staging** environment we’re going to spin up, and stress that endpoint as hard as possible in an environment as close to production as possible to get a sense of the load we can handle. In Pulumi we have Pulumi.yaml and Pulumi.<stack>.yaml. Think of the first as the “defaults” and the second as the dynamic per-stack override.

const config = new pulumi.Config();

const environment = config.require("environment");
const instanceType = config.require("instanceType");
const instanceCount = config.requireNumber("instanceCount");
const allowedCidrBlocks = config.requireObject<string[]>("allowedCidrBlocks");
This lets us keep a single code entry point and change whatever’s needed through per-stack config files, which makes it much easier to maintain the environment replica we need to ensure **staging** is as close as possible to **production**.

#Pulumi.yaml
name: pulumi-ec2-alb
runtime: nodejs
description: EC2 + Security Group + ALB example with Pulumi, structured for multiple environments (staging/prod)
config:
environment:
type: string
description: Environment name; used in prefixes and tags. Defined per stack.
instanceType:
type: string
description: EC2 instance type.
default: t3.micro
instanceCount:
type: integer
description: How many EC2 instances behind the ALB.
default: 1
allowedCidrBlocks:
type: array
items:
type: string
description: CIDRs allowed to reach the ALB on port 80.
default:
- 0.0.0.0/0

#Pulumi.prod.yaml
config:
aws:region: us-east-1
pulumi-ec2-alb:environment: prod
# prod overrides the defaults: bigger instance and more replicas.
pulumi-ec2-alb:instanceType: t3.small
pulumi-ec2-alb:instanceCount: 2
#Pulumi.staging.yaml
config:
aws:region: us-east-1
pulumi-ec2-alb:environment: staging
# staging identical to prod, we want it as close as possible.
pulumi-ec2-alb:instanceType: t3.small
pulumi-ec2-alb:instanceCount: 2

And what if we wanted to spin up a scaled-down **QA** environment, just for feature testing? Just run pulumi stack init qa and tweak the config file to the desired state.

#Pulumi.qa.yaml
config:
aws:region: us-east-1
# qa inherits almost everything from the Pulumi.yaml defaults
# (instanceType=t3.micro, instanceCount=1, allowedCidrBlocks=0.0.0.0/0).
# We only need to identify the environment:
pulumi-ec2-alb:environment: qa

All of it runs through this single entry point.

const servers: aws.ec2.Instance[] = [];
for (let i = 0; i < instanceCount; i++) {
servers.push(new aws.ec2.Instance(`${prefix}-web-${i}`, {
ami: ami.id,
instanceType: instanceType,
subnetId: subnets.ids.apply(ids => ids[i % ids.length]),
vpcSecurityGroupIds: [ec2Sg.id],
userData: userData,
tags: { ...commonTags, Name: `${prefix}-web-${i}` },
}));
}

## Wrapping up

This initial setup looks pretty simple, right? And it really is, but it still has a few traps and things to watch out for when you start thinking about scale and real environments. Complexity creeps in as we scale and we want to keep our IaC as the source of truth, including for our application’s runtime, which is very common in ECS-based applications for example, where we start splitting stacks not only by environment but also between what’s “volatile” and what’s “stable”. Here we even define which docker image tag is currently running on the app, and we can’t let image updates block or affect updates to the rest of the infrastructure, hence the volatile versus stable split.

[← back to /blog](/en/posts) END · 01.04

##### ── ON THIS PAGE

01Why multiple environments?02IaC structure to support multiple environments03Wrapping up

[READ NEXT → Why we need a staging environment Luck Ramos · 5 min](/en/posts/why-we-need-a-staging-environment)

---

# #aws · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/aws

> Posts tagged #aws from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:tag:aws clear all

[FEATURED · 01.04 ● INFRASTRUCTURE Jul 01, 2026 4 min How to structure a Pulumi IaC project for multiple environments M](/en/posts/structuring-iac-multi-environment)

per page122436100

---

# #cost · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/cost

> Posts tagged #cost from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:tag:cost clear all

[FEATURED · 01.04 ● DEVOPS Jun 24, 2026 5 min Why we need a staging environment Does keeping a replica of the productio](/en/posts/why-we-need-a-staging-environment)

per page122436100

---

# #devops · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/devops

> Posts tagged #devops from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 2

showing 1–2 of 2

updated 19:47 UTC

active filters:tag:devops clear all

[FEATURED · 01.04 ● INFRASTRUCTURE Jul 01, 2026 4 min How to structure a Pulumi IaC project for multiple environments M](/en/posts/structuring-iac-multi-environment)

[DEVOPS 01.05 Why we need a staging environment Luck Ramos Jun 24, 2026 · 5 min](/en/posts/why-we-need-a-staging-environment)

per page122436100

---

# #environments · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/environments

> Posts tagged #environments from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 2

showing 1–2 of 2

updated 19:47 UTC

active filters:tag:environments clear all

[FEATURED · 01.04 ● INFRASTRUCTURE Jul 01, 2026 4 min How to structure a Pulumi IaC project for multiple environments M](/en/posts/structuring-iac-multi-environment)

[DEVOPS 01.05 Why we need a staging environment Luck Ramos Jun 24, 2026 · 5 min](/en/posts/why-we-need-a-staging-environment)

per page122436100

---

# #iac · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/iac

> Posts tagged #iac from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:tag:iac clear all

[FEATURED · 01.04 ● INFRASTRUCTURE Jul 01, 2026 4 min How to structure a Pulumi IaC project for multiple environments M](/en/posts/structuring-iac-multi-environment)

per page122436100

---

# #pulumi · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/pulumi

> Posts tagged #pulumi from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:tag:pulumi clear all

[FEATURED · 01.04 ● INFRASTRUCTURE Jul 01, 2026 4 min How to structure a Pulumi IaC project for multiple environments M](/en/posts/structuring-iac-multi-environment)

per page122436100

---

# #reliability · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/reliability

> Posts tagged #reliability from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:tag:reliability clear all

[FEATURED · 01.04 ● DEVOPS Jun 24, 2026 5 min Why we need a staging environment Does keeping a replica of the productio](/en/posts/why-we-need-a-staging-environment)

per page122436100

---

# #staging · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/staging

> Posts tagged #staging from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:tag:staging clear all

[FEATURED · 01.04 ● DEVOPS Jun 24, 2026 5 min Why we need a staging environment Does keeping a replica of the productio](/en/posts/why-we-need-a-staging-environment)

per page122436100

---

# #terraform · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/terraform

> Posts tagged #terraform from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:tag:terraform clear all

[FEATURED · 01.04 ● INFRASTRUCTURE Jul 01, 2026 4 min How to structure a Pulumi IaC project for multiple environments M](/en/posts/structuring-iac-multi-environment)

per page122436100

---

# #testing · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/tag/testing

> Posts tagged #testing from Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01All posts00202DevOps00103Infrastructure001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸newest first▸oldest first▸longest reads▸random()

$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).

/blog · the index · MMXXVI

## All posts · 1

showing 1–1 of 1

updated 19:47 UTC

active filters:tag:testing clear all

[FEATURED · 01.04 ● DEVOPS Jun 24, 2026 5 min Why we need a staging environment Does keeping a replica of the productio](/en/posts/why-we-need-a-staging-environment)

per page122436100

---

# Why we need a staging environment · Luck Goes to Cloud

URL: https://blog.luckramos.com/en/posts/why-we-need-a-staging-environment

> Does keeping a replica of the production environment really matter? What does it get you?

[← back to /blog](/en/posts)

##### ── META

cat: **devops****
read: 5 min

words: 622

date: 2026-06-24

issue: 01.05**

##### ── AUTHOR

Luck Ramos

Tech Lead

##### ── SHARE

[↗ x.com](https://x.com/intent/tweet?text=Why%20we%20need%20a%20staging%20environment&url=https%3A%2F%2Fblog.luckramos.com%2Fen%2Fposts%2Fwhy-we-need-a-staging-environment%2F) [↗ hn](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fblog.luckramos.com%2Fen%2Fposts%2Fwhy-we-need-a-staging-environment%2F&t=Why%20we%20need%20a%20staging%20environment) [↗ email](mailto:?subject=Why%20we%20need%20a%20staging%20environment&#38;body=https%3A%2F%2Fblog.luckramos.com%2Fen%2Fposts%2Fwhy-we-need-a-staging-environment%2F)

##### ── FILED UNDER

[#staging](/en/posts/tag/staging)[#environments](/en/posts/tag/environments)[#devops](/en/posts/tag/devops)[#reliability](/en/posts/tag/reliability)[#cost](/en/posts/tag/cost)[#testing](/en/posts/tag/testing)

● DEVOPS 01.05 Jun 24, 2026 5 min

## Why we need a staging environment

Does keeping a replica of the production environment really matter? What does it get you?

FIG.1 · staging environment

It’s common, out there in the wild, to find companies that dig their heels in when the topic is creating a proper **staging** environment, claiming savings on infrastructure costs. Those same companies eventually run into critical **production** incidents that, almost as a rule, end up costing way more than the **staging** environment would have. Today we’ll go over what a staging environment really is, what purposes it serves, and strategies to mitigate the infrastructure cost of keeping one.

## The concept

The name “staging” refers to the final test before production; it comes from “stage testing”, the final tweaks in the most realistic scenario on stage, right before the show. This implies that **the staging environment has to always be as close to production as possible**, and when we say “as close as possible” we really mean in its entirety: not just the application’s features, but the network topology, security rules, scaling, databases, compute, error handling, observability alerts, authentication, capacity, and everything else you can think of. If it’s going to exist in production, it has to exist in staging too.

## The cost of risk

Knowing what a staging environment actually is (or should be), it becomes much easier to understand which consequences and risks we’re accepting when we choose not to keep a staging environment in our delivery flow. We accept that we’re exposed to any and all potential failures that aren’t application-level (and this is assuming the application’s features were at least tested beforehand). It’s accepting that an observability alert might not fire. It’s accepting that the database might blow past its active connection capacity during a traffic spike. It’s accepting that your server might not handle some heavy operation in your application. It’s accepting that there could be a security hole in some layer that wasn’t tested and checked beforehand, and now what’s exposed is your users. It’s always cheaper to skip the staging environment, right up until one of those bombs goes off.

Beyond just having a staging environment, it has to fully serve its purpose. It’s not enough to have a **“glorified QA environment”**, an environment with reduced compute, data far from reality, an altered network topology, or without production’s traffic volume. Want a few examples of how much a well-oiled staging environment is missed?

- Cloudflare - [Cloudflare outage on February 20, 2026](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)

- Gitlab - [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)

- Roblox - [Roblox Return to Service | Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021)

## How to minimize infra costs?

Even showing that it’s much cheaper to keep a staging environment than to run the risks of the alternative, for many companies it can still be an expensive investment that eats into margin. It’s desirable, but not always possible.

To work around this, we have a few strategies that mainly involve ephemerality and on-demand servers and services. This depends a lot on the reality and maturity of each development team, but considering delivery flows every sprint (usually two weeks), does it really make sense to keep environments idle and racking up costs? Most cloud services today offer ways to partially shut services down and cut costs. Pulling a few examples from AWS, Amazon Aurora recently started accepting **minCapacity 0**, which halts compute costs when it stops receiving connections. EC2 has **start/stop**, ECS has **desiredCount**, S3 has **Glacier**. The rule here is to provision only on demand, to cut idle costs as much as possible. Using **IaC**, most of these things can even be torn down completely and brought back as needed, if a **cold start** of a few hours (depending on scale) is acceptable for your team’s flow.

[← back to /blog](/en/posts) END · 01.05

##### ── ON THIS PAGE

01The concept02The cost of risk03How to minimize infra costs?

[READ NEXT → How to structure a Pulumi IaC project for multiple environments Luck Ramos · 4 min](/en/posts/structuring-iac-multi-environment)

---

# Luck Goes to Cloud

URL: https://blog.luckramos.com

Luck Goes to Cloud
Redirecting to [/en](/en). [Português](/pt).

---

# Redirecting to: /en/posts

URL: https://blog.luckramos.com/posts

Redirecting to: /en/posts [Redirecting from /posts/ to /en/posts](/en/posts)

---

# 404 · sinal perdido · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/404

> A página que você tentou acessar não está no arquivo. O sinal se perdeu entre o terminal e a nuvem.

── ERR · 404 · NAO_NO_INDICE

## 404

A página que você tentou acessar não está no arquivo. O sinal se perdeu entre o terminal e a nuvem.

[VOLTAR PARA O INÍCIO →](/pt) [EXPLORAR O ARQUIVO](/pt/posts)

---

# /sobre · quem sou eu? · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/about

> Quem escreve e como falar comigo.

$ whoami --verbose --since=2026

/about · the colophon · {aboutIssue}

--> Olá, me chamo Lucas Henrique Ramos mas geralmente você vai encontrar as pessoas me chamando por Luck (/luki/), tech lead, devops e resolvedor de problemas em tempo integral. Trabalho na UEEK e escrevo aqui sobre meus processos, decisões, problemas e soluções ao construir e escalar software.

Trabalho com tecnologia desde 2019 e já passei por vários projetos, clientes e gambiarras esquisitíssimas. Também já fui o responsável por bastante dessas gambiarras e acredito fielmente que fazer m%@#$ é uma das melhores formas de se aprender. Além do trabalho eu sou um completo aficcionado por música (o nome do blog é uma referência ao Milo Goes to College, do Descendents), moda, arte e tatuagens. Espero que encontre algo legal por aqui!

[EXPLORAR OS POSTS →](/pt/posts) [MANDE UM ALÔ](mailto:lukcramos@gmail.com)

── §02 · CANAIS

## Onde me encontrar

[01 $ git clone @luckramos ↗](https://github.com/luckramos)

[02 $ curl -L in/lukcramos ↗](https://www.linkedin.com/in/lukcramos)

[03 $ ssh -p 443 @lukcramos ↗](https://x.com/lukcramos)

[04 $ curl -L UEEK ↗](https://ueek.digital)

[05 $ echo | sendmail lukcramos@gmail.com ↗](mailto:lukcramos@gmail.com)

[06 $ tail -f /pt/rss.xml ↗](/pt/rss.xml)

── §03 · COLOPHON

## Como o blog é feito?

typeface (display)

Space Grotesk

typeface (mono)

JetBrains Mono

accent (dark)

#00FF41 · phosphor P1

accent (light)

#CC5500 · phosphor P3

built with

Astro · React · MDX

Achou um erro de português? Um problema de lógica? Uma opinião que você discordaria no bar? [Me conta](mailto:lukcramos@gmail.com)

---

# Luck Goes to Cloud

URL: https://blog.luckramos.com/pt

> Sobre arquitetura, cloud, devops, desenvolvimento e os processos do que eu construo no meu dia a dia.

VOL. I · NO. 01 MMXXVI · GENESIS

EM DESTAQUE · INFRAESTRUTURA ·
01.04

## luck:*goes*:cloud.

*Sobre arquitetura, cloud, devops, desenvolvimento e os processos do que eu construo no meu ***dia a dia.**

[EXPLORAR OS POSTS→](/pt/posts) [LER O MAIS RECENTE](/pt/posts/estruturando-iac-multi-ambiente) 2 posts · est. ∞

[01.06 · INFRAESTRUTURA Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes](/pt/posts/estruturando-iac-multi-ambiente)

[01.07 · DEVOPS Porquê precisamos de um ambiente de staging](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

.:=++***+=:.
-#@@@@@@@@@@@@@@@@#-
:%@@@@@@@@@%%%%%%%@@@@@@%-
-@@@@@@@@@%%%%%%%%%%%%%%@@@@@=
@@@@@@@@%%%%%%%%%%%%%%%%%%%%@@@@:
.@@@@@@@@@@%%%%%%%%%%%%%%@@@@@@@%%@=
.@@@@@%###@@@@@%%%%%%%%@@@@%**#%@@@@@+
@@#- =@@@@@@@@@@- -*%@-
. *%%@@@@%= *@@@@@@- +%@@@@@*:
=@@@@*. =#@@- +@@#- .+@@@@
@ %#@@ @@ @@ -- -@% @@ @@@% .@+
.@- %@@@ *@ @@@@ -@+ @@@# +@*
.@@ @@@* -@* :@@@@. %@- *@@@ %@*
.@@% +@@@@%%@@- :@@@@@@. -@@%%@@@@+ %%@*
@@@@- :-=- *@@@%%@@@* :--: -%##%*
#@%%@@@#=-::-+%@@@@@@@@@@@@%*--:-=*%%%%*#%
@@%%%%%@@@@@@@@@@@: .@%@@@@@@@@%%%#**%@:
@@@%%%%%%%%%%%%%%%@=------=%%%%%%%%%%%%%#*#%@@=
@@%%%#%%%%%%%%%%%%%%@@@@@@@@%%%%%%%%%%%%%#*#@@@@+
@@@@%#*%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%####%#**%@@@@:
*@@@@#++%%%%%%%%%%%%%%%%%%%%%%%%#%%%######%#=+#@@@@@
-@@@%==*%%%%%%%%%%%%%%%%%%#%%#####%%#%%###%#*=+*@@@%
:. #%%%%%%%%%%%%%%%%%%%#%%%%%%##%%#####%#*#: .-:
@@%%%%%*#%%%%%%%%%%%#%%#####%%#+*#%%%**%-
@@%%#%#**#%%####%%%%%%%#####%%***#%%%**@:
#@%%%%#*##%%%%%%%%%##%%%%##%%#****%%#*#@
=@%%%%#%%%%%%%%%%%*####%%%%%%##%%###**#%
@@@@@#:.=@@%%%%%%%**#%%%%%%%%*-:+%%#%@+
#%%+ %@@@@@* =%@%%%%- :#%%=
:+*+: =*+-

FIG.01 · 「ghost」

722 frames @ 30fps

render · ascii · 130×38

loop · 24.1s/cycle

---

# DevOps · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/category/DevOps

> Posts na categoria DevOps no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## DevOps · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:cat:devops limpar tudo

[DESTAQUE · 01.04 ● DEVOPS 24 de jun. de 2026 5 min Porquê precisamos de um ambiente de staging Manter uma réplica do a](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

por página122436100

---

# Infraestrutura · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/category/Infraestrutura

> Posts na categoria Infraestrutura no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Infraestrutura · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:cat:infraestrutura limpar tudo

[DESTAQUE · 01.04 ● INFRAESTRUTURA 01 de jul. de 2026 4 min Como estruturar um projeto de IaC com Pulumi para múltiplos](/pt/posts/estruturando-iac-multi-ambiente)

por página122436100

---

# Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/estruturando-iac-multi-ambiente

> Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível

[← voltar para /blog](/pt/posts)

##### ── META

cat: **infraestrutura****
read: 4 min

words: 958

date: 2026-07-01

issue: 01.04**

##### ── AUTHOR

*

Luck Ramos

Tech Lead

##### ── SHARE

[↗ x.com](https://x.com/intent/tweet?text=Como%20estruturar%20um%20projeto%20de%20IaC%20com%20Pulumi%20para%20m%C3%BAltiplos%20ambientes&url=https%3A%2F%2Fblog.luckramos.com%2Fpt%2Fposts%2Festruturando-iac-multi-ambiente%2F) [↗ hn](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fblog.luckramos.com%2Fpt%2Fposts%2Festruturando-iac-multi-ambiente%2F&t=Como%20estruturar%20um%20projeto%20de%20IaC%20com%20Pulumi%20para%20m%C3%BAltiplos%20ambientes) [↗ email](mailto:?subject=Como%20estruturar%20um%20projeto%20de%20IaC%20com%20Pulumi%20para%20m%C3%BAltiplos%20ambientes&#38;body=https%3A%2F%2Fblog.luckramos.com%2Fpt%2Fposts%2Festruturando-iac-multi-ambiente%2F)

##### ── FILED UNDER

[#iac](/pt/posts/tag/iac)[#pulumi](/pt/posts/tag/pulumi)[#terraform](/pt/posts/tag/terraform)[#aws](/pt/posts/tag/aws)[#devops](/pt/posts/tag/devops)[#environments](/pt/posts/tag/environments)

● INFRAESTRUTURA 01.04 01 de jul. de 2026 4 min

## Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes

Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível

FIG.1 · diagrama IaC

Acho que inegávelmente um dos principais pontos quando começamos os estudos sobre infraestrutura, cloud, devops e etc é IaC. Versionamento de código sempre foi considerado como um dos cernes do desenvolvimento, é indiscutível que a maioria esmagadora dos softwares existentes no mercado hoje tem um repositório git por trás, e tudo isso só pra poder dar um blame* em uma gambiarra de 6 meses atrás e descobrir que foi a gente mesmo que fez.

**Infraestrutura como código** vem justamente pra trazer toda a graça do VSC pra nossa construção de ambientes e fortifica algumas práticas essenciais como reprodutibilidade. Nesse post quero decorrer sobre como estruturar sua infraestrutura como código para suportar múltiplos ambientes.

## Por que múltiplos ambientes?

Software é algo previsivelmente imprevisível, tanto é que uma das disciplinas mais famosas que temos é o **chaos engineering**, feito justamente para tentar garantir o máximo possível de resiliência nessas situações imprevisíveis e aleatórias, caóticas. Um dos processos dentro da garantia de qualidade é o teste de features e entregáveis em multiplos ambientes antes da produção.

**Dev**: O ambiente que o desenvolvedor vai trabalhar é tido comumente como o ambiente de **dev/develop/desenvolvimento**. Pode ele ser local, cloud, virtualizado, uma VPS, um WSL, independente, é o ambiente onde o nosso desenvolvedor vai construir e ajustar do zero.

**Homolog**: Aqui é geralmente onde o time de QA vai testar a feature e a integração de ponta-a-ponta em um ambiente isolado e seguro. O cliente não têm acesso, é interno.

**Staging**: Bem semelhante ao ambiente de homologação mas com a ressalva de que a idéia aqui é ele ser um réplica exata do ambiente de produção. Muito útil para testes de estresse e capacity planning.

**Produção**: Ambiente final, clientes acessam.

A ideia do fluxo é sempre promover uma feature entre esses ambientes. É comum encontrar fluxos onde só exista um ambiente de homologação e não um de staging, ou só um de staging que serve como homologação também, ou os que não tem nenhum e testam direto em produção rezando pra não quebrar nada.

## Estrutura IaC para suportar múltiplos ambientes

Vou usar aqui o **Pulumi** para exemplo, mas todos os conceitos aqui discutidos podem ser aplicados em outras ferramentas como **Terraform**.

Um dos conceitos mais difundidos aqui é que uma **stack** *(workspace no caso do Terraform)* equivale sempre a um **ambiente**. Considere o seguinte.

Nós criamos um endpoint novo na nossa API e precisamos validar o funcionamento dela de ponta-a-ponta em um ambiente de **staging** que vamos criar, e estressar esse endpoint ao máximo em um ambiente o mais próximo possível do de produção para ter noção da carga que aguentamos. No Pulumi, temos os Pulumi.yaml e Pulumi.<stack>.yaml. Considere o primeiro como os “defaults” e o segundo como o override dinâmico por stack.

const config = new pulumi.Config();

const environment = config.require("environment");
const instanceType = config.require("instanceType");
const instanceCount = config.requireNumber("instanceCount");
const allowedCidrBlocks = config.requireObject<string[]>("allowedCidrBlocks");
Isso nos possibilita ter uma única entrada de código e alterar o que for necessário via arquivos de configuração por stack, o que facilita muito mantermos a réplica de ambiente necessária para garantir que **staging** está o mais próximo possível de **production**.

#Pulumi.yaml
name: pulumi-ec2-alb
runtime: nodejs
description: Exemplo de EC2 + Security Group + ALB com Pulumi, estruturado para múltiplos ambientes (staging/prod)
config:
environment:
type: string
description: Nome do ambiente; usado em prefixos e tags. Definido por cada stack.
instanceType:
type: string
description: Tipo da instância EC2.
default: t3.micro
instanceCount:
type: integer
description: Quantas instâncias EC2 atrás do ALB.
default: 1
allowedCidrBlocks:
type: array
items:
type: string
description: CIDRs liberados para acessar o ALB na porta 80.
default:
- 0.0.0.0/0

#Pulumi.prod.yaml
config:
aws:region: us-east-1
pulumi-ec2-alb:environment: prod
# prod sobrescreve os defaults: instância maior e mais réplicas.
pulumi-ec2-alb:instanceType: t3.small
pulumi-ec2-alb:instanceCount: 2
#Pulumi.staging.yaml
config:
aws:region: us-east-1
pulumi-ec2-alb:environment: staging
# staging idêntico a prod, queremos o mais próximo possível.
pulumi-ec2-alb:instanceType: t3.small
pulumi-ec2-alb:instanceCount: 2

E se quiséssemos subir um ambiente de **homologação**, reduzido, somente para testes de features? Basta um pulumi stack init homolog e ajustar o arquivo de configuração conforme o estado desejado

#Pulumi.homolog.yaml
config:
aws:region: us-east-1
# homolog herda quase tudo dos defaults do Pulumi.yaml
# (instanceType=t3.micro, instanceCount=1, allowedCidrBlocks=0.0.0.0/0).
# Só precisamos identificar o ambiente:
pulumi-ec2-alb:environment: homolog

Tudo isso para rodar nesse único entrypoint.

const servers: aws.ec2.Instance[] = [];
for (let i = 0; i < instanceCount; i++) {
servers.push(new aws.ec2.Instance(`${prefix}-web-${i}`, {
ami: ami.id,
instanceType: instanceType,
subnetId: subnets.ids.apply(ids => ids[i % ids.length]),
vpcSecurityGroupIds: [ec2Sg.id],
userData: userData,
tags: { ...commonTags, Name: `${prefix}-web-${i}` },
}));
}

## Pra fechar

Esse setup inicial parece bem simples né? E realmente é, mas ainda sim tem algumas armadilhas e cuidados que devemos tomar pensando em escala e ambientes reais. A complexidade vai entrando conforme vamos escalando e queremos manter nossa IaC como fonte da verdade inclusive do runtime da nossa aplicação, o que é bem comum em aplicações com ECS por exemplo, onde começamos a separar as stacks não só por ambiente mas também entre o que é “volátil” e o que é “estável”, aqui definimos até qual a tag da imagem docker rodando atualmente na aplicação, e não podemos que updates de imagem travem ou afetem updates no restante da infraestrutura, vide o que é volátil e o que é estável.

## Precisa de ajuda?

Sente que precisa de ajuda pra estruturar a sua própria infraestrutura ou algo do que eu falei aqui faz sentido pra você mas sente que é muito complicado fazer por conta? Aqui na [UEEK](https://ueek.digital/) a gente fornece esse tipo de consultoria pra facilitar sua estruturação de DevOps, desde infraestrutura até CI/CD, segurança e observabilidade. [Clica aqui](https://consultorias.ueek.digital/diagnostico-devsecops) e confere gratuitamente!

[← voltar para /blog](/pt/posts) END · 01.04

##### ── ON THIS PAGE

01Por que múltiplos ambientes?02Estrutura IaC para suportar múltiplos ambientes03Pra fechar04Precisa de ajuda?

[PRÓXIMA

---

# /blog · o índice · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts

> Lista completa de posts do Luck Goes to Cloud, anotações sobre arquitetura, cloud, system design e desenvolvimento de sistemas.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 2

mostrando 1–2 de 2

atualizado 19:47 UTC

filtros ativos:nenhum

[DESTAQUE · 01.04 ● INFRAESTRUTURA 01 de jul. de 2026 4 min Como estruturar um projeto de IaC com Pulumi para múltiplos](/pt/posts/estruturando-iac-multi-ambiente)

[DEVOPS 01.05 Porquê precisamos de um ambiente de staging Luck Ramos 24 de jun. de 2026 · 5 min](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

por página122436100

---

# Porquê precisamos de um ambiente de staging · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/porque-precisamos-de-um-ambiente-de-staging

> Manter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?

[← voltar para /blog](/pt/posts)

##### ── META

cat: **devops****
read: 5 min

words: 789

date: 2026-06-24

issue: 01.05**

##### ── AUTHOR

Luck Ramos

Tech Lead

##### ── SHARE

[↗ x.com](https://x.com/intent/tweet?text=Porqu%C3%AA%20precisamos%20de%20um%20ambiente%20de%20staging&url=https%3A%2F%2Fblog.luckramos.com%2Fpt%2Fposts%2Fporque-precisamos-de-um-ambiente-de-staging%2F) [↗ hn](https://news.ycombinator.com/submitlink?u=https%3A%2F%2Fblog.luckramos.com%2Fpt%2Fposts%2Fporque-precisamos-de-um-ambiente-de-staging%2F&t=Porqu%C3%AA%20precisamos%20de%20um%20ambiente%20de%20staging) [↗ email](mailto:?subject=Porqu%C3%AA%20precisamos%20de%20um%20ambiente%20de%20staging&#38;body=https%3A%2F%2Fblog.luckramos.com%2Fpt%2Fposts%2Fporque-precisamos-de-um-ambiente-de-staging%2F)

##### ── FILED UNDER

[#staging](/pt/posts/tag/staging)[#environments](/pt/posts/tag/environments)[#devops](/pt/posts/tag/devops)[#reliability](/pt/posts/tag/reliability)[#cost](/pt/posts/tag/cost)[#testing](/pt/posts/tag/testing)

● DEVOPS 01.05 24 de jun. de 2026 5 min

## Porquê precisamos de um ambiente de staging

Manter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?

FIG.1 · ambiente de Staging

É comum encontrar se aventurando por aí, empresas que batem o pé quando o assunto é criar ambientes de **staging** propriamente ditos alegando uma economia nos custos de infraestrutura. Essas mesmas empresas eventualmente esbarram em incidentes críticos em **produção** que quase que via de regra acabam custando muito mais do que o dito ambiente de **staging**. Hoje vamos discorrer o que realmente é um ambiente de staging, quais propósitos ele cumpre e estratégias para mitigar o custo de infraestrutura ao manter um.

## Conceito

O nome “staging” é o teste final antes de produção, vem de “stage testing”, e são os ajustes finais no cenário mais próximo da realidade no palco, antes da apresentação. Com isso, implica-se que **o ambiente de staging tem que ser sempre o mais próximo possível de production**, e quando falamos “mais próximo possível” é realmente em sua completude, não somente as features da aplicação, mas a topologia de rede, regras de segurança, scaling, bancos de dados, compute, tratamento de erros, alertas de observabilidade, autenticação, capacidade e tudo que se tem direito. Se vai existir em production, deve existir também em staging.

## Custo do risco

Sabendo o que é (ou deveria ser) um ambiente de staging propriamente dito, fica muito mais fácil entender quais as consequências e riscos que aceitamos assumir quando escolhemos não manter um ambiente de staging no nosso fluxo de entrega. Aceitamos que estamos suscetíveis a todas e quaisquer potenciais falhas que não sejam de aplicação (isso considerando que pelo menos as features da aplicação foram testadas previamente). É aceitar que um alerta de observabilidade pode não disparar. É aceitar que o banco de dados pode estourar a capacidade de conexões ativas em um pico de acesso. É aceitar que seu servidor pode não aguentar alguma operação pesada da sua aplicação. É aceitar que pode existir uma brecha de segurança em alguma camada que não foi testada e conferida antes e agora o que está exposto são os seus usuários. É sempre mais barato não ter um ambiente de staging até o momento que uma dessas bombas exploda.

Além de ter um ambiente de staging, ele precisa cumprir seu propósito por completo. Não basta ter uma **“homologação tunada”**, um ambiente com compute reduzido, dados distantes da realidade, topologia de rede alterada ou sem o volume de tráfego de produção Quer alguns exemplos de como um ambiente de staging bem azeitado faz falta?

- Cloudflare - [Cloudflare outage on February 20, 2026](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)

- Gitlab - [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)

- Roblox - [Roblox Return to Service | Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021)

## Como minimizar os custos de infra?

Mesmo demonstrando que é muito mais barato manter um ambiente de staging do que correr os riscos do contrário, para muitas empresas ainda pode ser um investimento caro, que reduz margem. É desejável, mas nem sempre é possível.

Para contornar isso, temos algumas estratégias que envolvem principalmente efemeridade, servidores e serviços sob demanda. Isso depende muito da realidade e maturidade de cada time de desenvolvimento, mas considerando fluxos de entregas a cada sprint (geralmente duas semanas), faz mesmo sentido mantermos os ambientes em idle gerando custos? A maioria dos serviços cloud hoje oferece recursos para interromper parcialmente serviços e reduzir custos. Puxando alguns exemplos da AWS, o Amazon Aurora recentemente passou a aceitar **minCapacity 0** o que interrompe os custos de compute quando não recebe mais conexões. EC2 tem o **start/stop**, ECS tem o **desiredCount**, S3 tem o **Glacier**. A regra aqui é provisionar somente sob demanda para cortar ao máximo os custos quando em idle. Utilizando **IaC**, a maioria dessas coisas podem até ser completamente derrubadas e reestabelecidas conforme a necessidade, se o **cold start** de algumas horas (a depender da escala) for aceitável pro fluxo do seu time.

## Para onde ir agora?

Apesar de tudo isso que eu falei aqui, é muito, muito comum mesmo empresas e times que aplicam esses **multi-ambientes** de forma errada ou subótima, e é um problema que eu tenho certeza que até quem faz certo hoje já enfrentou antes. A gente só aprende mesmo depois de sofrer com a cagada de não ter feito mais cedo.

Aqui na [UEEK](https://ueek.digital/) mesmo a gente já sofreu muito por não ter ambiente de testes antes, ou não ter uma réplica fiel de produção para testar toda a operação de ponta a ponta e encontrar os problemas antes que chegassem nos clientes, e a gente aprendeu tanto com esse tipo de problema que hoje a gente consegue oferecer uma ajudinha pra quem não quer passar pelo mesmo que a gente. Se interessou? [Clica aqui e dá uma olhada, é grátis!](https://consultorias.ueek.digital/diagnostico-devsecops)

[← voltar para /blog](/pt/posts) END · 01.05

##### ── ON THIS PAGE

01Conceito02Custo do risco03Como minimizar os custos de infra?04Para onde ir agora?

[PRÓXIMA LEITURA → Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes Luck Ramos · 4 min](/pt/posts/estruturando-iac-multi-ambiente)

---

# #aws · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/aws

> Posts com a tag #aws no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:tag:aws limpar tudo

[DESTAQUE · 01.04 ● INFRAESTRUTURA 01 de jul. de 2026 4 min Como estruturar um projeto de IaC com Pulumi para múltiplos](/pt/posts/estruturando-iac-multi-ambiente)

por página122436100

---

# #cost · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/cost

> Posts com a tag #cost no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:tag:cost limpar tudo

[DESTAQUE · 01.04 ● DEVOPS 24 de jun. de 2026 5 min Porquê precisamos de um ambiente de staging Manter uma réplica do a](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

por página122436100

---

# #devops · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/devops

> Posts com a tag #devops no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 2

mostrando 1–2 de 2

atualizado 19:47 UTC

filtros ativos:tag:devops limpar tudo

[DESTAQUE · 01.04 ● INFRAESTRUTURA 01 de jul. de 2026 4 min Como estruturar um projeto de IaC com Pulumi para múltiplos](/pt/posts/estruturando-iac-multi-ambiente)

[DEVOPS 01.05 Porquê precisamos de um ambiente de staging Luck Ramos 24 de jun. de 2026 · 5 min](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

por página122436100

---

# #environments · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/environments

> Posts com a tag #environments no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 2

mostrando 1–2 de 2

atualizado 19:47 UTC

filtros ativos:tag:environments limpar tudo

[DESTAQUE · 01.04 ● INFRAESTRUTURA 01 de jul. de 2026 4 min Como estruturar um projeto de IaC com Pulumi para múltiplos](/pt/posts/estruturando-iac-multi-ambiente)

[DEVOPS 01.05 Porquê precisamos de um ambiente de staging Luck Ramos 24 de jun. de 2026 · 5 min](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

por página122436100

---

# #iac · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/iac

> Posts com a tag #iac no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:tag:iac limpar tudo

[DESTAQUE · 01.04 ● INFRAESTRUTURA 01 de jul. de 2026 4 min Como estruturar um projeto de IaC com Pulumi para múltiplos](/pt/posts/estruturando-iac-multi-ambiente)

por página122436100

---

# #pulumi · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/pulumi

> Posts com a tag #pulumi no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:tag:pulumi limpar tudo

[DESTAQUE · 01.04 ● INFRAESTRUTURA 01 de jul. de 2026 4 min Como estruturar um projeto de IaC com Pulumi para múltiplos](/pt/posts/estruturando-iac-multi-ambiente)

por página122436100

---

# #reliability · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/reliability

> Posts com a tag #reliability no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:tag:reliability limpar tudo

[DESTAQUE · 01.04 ● DEVOPS 24 de jun. de 2026 5 min Porquê precisamos de um ambiente de staging Manter uma réplica do a](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

por página122436100

---

# #staging · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/staging

> Posts com a tag #staging no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:tag:staging limpar tudo

[DESTAQUE · 01.04 ● DEVOPS 24 de jun. de 2026 5 min Porquê precisamos de um ambiente de staging Manter uma réplica do a](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

por página122436100

---

# #terraform · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/terraform

> Posts com a tag #terraform no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:tag:terraform limpar tudo

[DESTAQUE · 01.04 ● INFRAESTRUTURA 01 de jul. de 2026 4 min Como estruturar um projeto de IaC com Pulumi para múltiplos](/pt/posts/estruturando-iac-multi-ambiente)

por página122436100

---

# #testing · /blog · Luck Goes to Cloud

URL: https://blog.luckramos.com/pt/posts/tag/testing

> Posts com a tag #testing no Luck Goes to Cloud.

#### ── SEARCH

/

#### ── CATALOG · MMXXVI

**01Todos os posts00202DevOps00103Infraestrutura001

#### ── BY YEAR

2026

#### ── TAGS

#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing

#### ── SORT BY

▸mais recentes▸mais antigos▸leituras mais longas▸random()

$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).

/blog · the index · MMXXVI

## Todos os posts · 1

mostrando 1–1 de 1

atualizado 19:47 UTC

filtros ativos:tag:testing limpar tudo

[DESTAQUE · 01.04 ● DEVOPS 24 de jun. de 2026 5 min Porquê precisamos de um ambiente de staging Manter uma réplica do a](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)

por página122436100

---

# Redirecting to: /en/rss.xml

URL: https://blog.luckramos.com/rss.xml

Redirecting to: /en/rss.xml [Redirecting from /rss.xml/ to /en/rss.xml](/en/rss.xml)

---

# How to structure a Pulumi IaC project for multiple environments

Source: posts/en/structuring-iac-multi-environment.mdx

> Multiple environments and how to structure them in a single reproducible project

import CRTFrame from '~/components/post/CRTFrame.astro';

<CRTFrame
     src="/posts/estruturando-iac-multi-ambiente/banner.png"
     alt="Illustration of an IaC diagram"
     caption="FIG.1 · IaC diagram"
/>

I'd say undeniably one of the main things when we start studying infrastructure, cloud, devops and so on is IaC. Code versioning has always been considered one of the cores of software development. It's indisputable that the overwhelming majority of the software out in the market today has a git repository behind it, and all that just so we can *blame* some hack from 6 months ago and find out we were the ones who wrote it.

**Infrastructure as Code** comes precisely to bring all the goodness of VCS to our environment building, and it reinforces essential practices like reproducibility. In this post I want to walk through how to structure your infrastructure as code to support multiple environments.

### Why multiple environments?

Software is something predictably unpredictable, so much so that one of the most famous disciplines we have is **chaos engineering**, created precisely to try to guarantee as much resilience as possible in those unpredictable, random, chaotic situations. One of the processes within quality assurance is testing features and deliverables across multiple environments before production.

**Dev**: The environment where the developer works is commonly referred to as the **dev/develop/development** environment. It can be local, cloud, virtualized, a VPS, a WSL, whatever; it's the environment where our developer builds and tweaks things from scratch.

**QA**: This is usually where the QA team tests the feature and its end-to-end integration in an isolated, secure environment. The client has no access; it's internal.

**Staging**: Very similar to the QA environment, but with the caveat that the idea here is for it to be an exact replica of the production environment. Very useful for stress testing and capacity planning.

**Production**: The final environment, where clients access.

The idea behind the flow is to always promote a feature across these environments. It's common to find flows where there's only a QA environment and no staging, or only a staging that doubles as QA, or the ones that have none of it and test straight in production, praying nothing breaks.

### IaC structure to support multiple environments

I'll use **Pulumi** here for the example, but all the concepts discussed here can be applied to other tools like **Terraform**.

One of the most widespread concepts here is that a **stack** *(a workspace in Terraform's case)* always maps to one **environment**. Consider the following.

We added a new endpoint to our API and we need to validate that it works end-to-end in a **staging** environment we're going to spin up, and stress that endpoint as hard as possible in an environment as close to production as possible to get a sense of the load we can handle. In Pulumi we have ``Pulumi.yaml`` and ``Pulumi.<stack>.yaml``. Think of the first as the "defaults" and the second as the dynamic per-stack override.

```typescript
const config = new pulumi.Config();

const environment = config.require("environment");
const instanceType = config.require("instanceType");
const instanceCount = config.requireNumber("instanceCount");
const allowedCidrBlocks = config.requireObject<string[]>("allowedCidrBlocks");
```

This lets us keep a single code entry point and change whatever's needed through per-stack config files, which makes it much easier to maintain the environment replica we need to ensure **staging** is as close as possible to **production**.

```yml
#Pulumi.yaml
name: pulumi-ec2-alb
runtime: nodejs
description: EC2 + Security Group + ALB example with Pulumi, structured for multiple environments (staging/prod)
config:
  environment:
    type: string
    description: Environment name; used in prefixes and tags. Defined per stack.
  instanceType:
    type: string
    description: EC2 instance type.
    default: t3.micro
  instanceCount:
    type: integer
    description: How many EC2 instances behind the ALB.
    default: 1
  allowedCidrBlocks:
    type: array
    items:
      type: string
    description: CIDRs allowed to reach the ALB on port 80.
    default:
      - 0.0.0.0/0

```

```yml
#Pulumi.prod.yaml
config:
  aws:region: us-east-1
  pulumi-ec2-alb:environment: prod
  # prod overrides the defaults: bigger instance and more replicas.
  pulumi-ec2-alb:instanceType: t3.small
  pulumi-ec2-alb:instanceCount: 2
```

```yml
#Pulumi.staging.yaml
config:
  aws:region: us-east-1
  pulumi-ec2-alb:environment: staging
  # staging identical to prod, we want it as close as possible.
  pulumi-ec2-alb:instanceType: t3.small
  pulumi-ec2-alb:instanceCount: 2

```

And what if we wanted to spin up a scaled-down **QA** environment, just for feature testing? Just run ``pulumi stack init qa`` and tweak the config file to the desired state.

```yml
#Pulumi.qa.yaml
config:
  aws:region: us-east-1
  # qa inherits almost everything from the Pulumi.yaml defaults
  # (instanceType=t3.micro, instanceCount=1, allowedCidrBlocks=0.0.0.0/0).
  # We only need to identify the environment:
  pulumi-ec2-alb:environment: qa

```

All of it runs through this single entry point.

```typescript

const servers: aws.ec2.Instance[] = [];
for (let i = 0; i < instanceCount; i++) {
    servers.push(new aws.ec2.Instance(`${prefix}-web-${i}`, {
        ami: ami.id,
        instanceType: instanceType,
        subnetId: subnets.ids.apply(ids => ids[i % ids.length]),
        vpcSecurityGroupIds: [ec2Sg.id],
        userData: userData,
        tags: { ...commonTags, Name: `${prefix}-web-${i}` },
    }));
}

```

### Wrapping up

This initial setup looks pretty simple, right? And it really is, but it still has a few traps and things to watch out for when you start thinking about scale and real environments. Complexity creeps in as we scale and we want to keep our IaC as the source of truth, including for our application's runtime, which is very common in ECS-based applications for example, where we start splitting stacks not only by environment but also between what's "volatile" and what's "stable". Here we even define which docker image tag is currently running on the app, and we can't let image updates block or affect updates to the rest of the infrastructure, hence the volatile versus stable split.



---

# Why we need a staging environment

Source: posts/en/why-we-need-a-staging-environment.mdx

> Does keeping a replica of the production environment really matter? What does it get you?

import CRTFrame from '~/components/post/CRTFrame.astro';

<CRTFrame
     src="/posts/porque-ambiente-staging/banner.png"
     alt="Illustration of a stage in black and white"
     caption="FIG.1 · staging environment"
/>

It's common, out there in the wild, to find companies that dig their heels in when the topic is creating a proper **staging** environment, claiming savings on infrastructure costs. Those same companies eventually run into critical **production** incidents that, almost as a rule, end up costing way more than the **staging** environment would have. Today we'll go over what a staging environment really is, what purposes it serves, and strategies to mitigate the infrastructure cost of keeping one.

### The concept

The name "staging" refers to the final test before production; it comes from "stage testing", the final tweaks in the most realistic scenario on stage, right before the show. This implies that **the staging environment has to always be as close to production as possible**, and when we say "as close as possible" we really mean in its entirety: not just the application's features, but the network topology, security rules, scaling, databases, compute, error handling, observability alerts, authentication, capacity, and everything else you can think of. If it's going to exist in production, it has to exist in staging too.

### The cost of risk

Knowing what a staging environment actually is (or should be), it becomes much easier to understand which consequences and risks we're accepting when we choose not to keep a staging environment in our delivery flow. We accept that we're exposed to any and all potential failures that aren't application-level (and this is assuming the application's features were at least tested beforehand). It's accepting that an observability alert might not fire. It's accepting that the database might blow past its active connection capacity during a traffic spike. It's accepting that your server might not handle some heavy operation in your application. It's accepting that there could be a security hole in some layer that wasn't tested and checked beforehand, and now what's exposed is your users. It's always cheaper to skip the staging environment, right up until one of those bombs goes off.

Beyond just having a staging environment, it has to fully serve its purpose. It's not enough to have a **"glorified QA environment"**, an environment with reduced compute, data far from reality, an altered network topology, or without production's traffic volume. Want a few examples of how much a well-oiled staging environment is missed?

- Cloudflare - [Cloudflare outage on February 20, 2026](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)
- Gitlab - [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)
- Roblox - [Roblox Return to Service \| Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021)

### How to minimize infra costs?

Even showing that it's much cheaper to keep a staging environment than to run the risks of the alternative, for many companies it can still be an expensive investment that eats into margin. It's desirable, but not always possible.

To work around this, we have a few strategies that mainly involve ephemerality and on-demand servers and services. This depends a lot on the reality and maturity of each development team, but considering delivery flows every sprint (usually two weeks), does it really make sense to keep environments idle and racking up costs? Most cloud services today offer ways to partially shut services down and cut costs. Pulling a few examples from AWS, Amazon Aurora recently started accepting **minCapacity 0**, which halts compute costs when it stops receiving connections. EC2 has **start/stop**, ECS has **desiredCount**, S3 has **Glacier**. The rule here is to provision only on demand, to cut idle costs as much as possible. Using **IaC**, most of these things can even be torn down completely and brought back as needed, if a **cold start** of a few hours (depending on scale) is acceptable for your team's flow.



---

# posts/pt/estruturando-iac-multi-ambiente.mdx

Source: posts/pt/estruturando-iac-multi-ambiente.mdx


---
title: Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes
description: "Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível"
category: Infraestrutura
publishedAt: 2026-07-01
tags:
  - iac
  - pulumi
  - terraform
  - aws
  - devops
  - environments
author:
  name: Luck Ramos
  role: Tech Lead
  avatar: /authors/luckramos.jpeg
featured: true
draft: false
readingTime: 4
translationKey: iac-multi-environment
---

import CRTFrame from '~/components/post/CRTFrame.astro';

<CRTFrame
     src="/posts/estruturando-iac-multi-ambiente/banner.png"
     alt="Ilustração de um diagrama sobre IaC"
     caption="FIG.1 · diagrama IaC"
/>

Acho que inegávelmente um dos principais pontos quando começamos os estudos sobre infraestrutura, cloud, devops e etc é IaC. Versionamento de código sempre foi considerado como um dos cernes do desenvolvimento, é indiscutível que a maioria esmagadora dos softwares existentes no mercado hoje tem um repositório git por trás, e tudo isso só pra poder dar um *blame* em uma gambiarra de 6 meses atrás e descobrir que foi a gente mesmo que fez.

**Infraestrutura como código** vem justamente pra trazer toda a graça do VSC pra nossa construção de ambientes e fortifica algumas práticas essenciais como reprodutibilidade. Nesse post quero decorrer sobre como estruturar sua infraestrutura como código para suportar múltiplos ambientes.

### Por que múltiplos ambientes?

Software é algo previsivelmente imprevisível, tanto é que uma das disciplinas mais famosas que temos é o **chaos engineering**, feito justamente para tentar garantir o máximo possível de resiliência nessas situações imprevisíveis e aleatórias, caóticas. Um dos processos dentro da garantia de qualidade é o teste de features e entregáveis em multiplos ambientes antes da produção.

**Dev**: O ambiente que o desenvolvedor vai trabalhar é tido comumente como o ambiente de **dev/develop/desenvolvimento**. Pode ele ser local, cloud, virtualizado, uma VPS, um WSL, independente, é o ambiente onde o nosso desenvolvedor vai construir e ajustar do zero.

**Homolog**: Aqui é geralmente onde o time de QA vai testar a feature e a integração de ponta-a-ponta em um ambiente isolado e seguro. O cliente não têm acesso, é interno.

**Staging**: Bem semelhante ao ambiente de homologação mas com a ressalva de que a idéia aqui é ele ser um réplica exata do ambiente de produção. Muito útil para testes de estresse e capacity planning.

**Produção**: Ambiente final, clientes acessam.

A ideia do fluxo é sempre promover uma feature entre esses ambientes. É comum encontrar fluxos onde só exista um ambiente de homologação e não um de staging, ou só um de staging que serve como homologação também, ou os que não tem nenhum e testam direto em produção rezando pra não quebrar nada.

### Estrutura IaC para suportar múltiplos ambientes

Vou usar aqui o **Pulumi** para exemplo, mas todos os conceitos aqui discutidos podem ser aplicados em outras ferramentas como **Terraform**.

Um dos conceitos mais difundidos aqui é que uma **stack** *(workspace no caso do Terraform)* equivale sempre a um **ambiente**. Considere o seguinte.

Nós criamos um endpoint novo na nossa API e precisamos validar o funcionamento dela de ponta-a-ponta em um ambiente de **staging** que vamos criar, e estressar esse endpoint ao máximo em um ambiente o mais próximo possível do de produção para ter noção da carga que aguentamos. No Pulumi, temos os ``Pulumi.yaml`` e ``Pulumi.<stack>.yaml``. Considere o primeiro como os "defaults" e o segundo como o override dinâmico por stack.

```typescript
const config = new pulumi.Config();

const environment = config.require("environment");
const instanceType = config.require("instanceType");
const instanceCount = config.requireNumber("instanceCount");
const allowedCidrBlocks = config.requireObject<string[]>("allowedCidrBlocks");
```

Isso nos possibilita ter uma única entrada de código e alterar o que for necessário via arquivos de configuração por stack, o que facilita muito mantermos a réplica de ambiente necessária para garantir que **staging** está o mais próximo possível de **production**.

```yml
#Pulumi.yaml
name: pulumi-ec2-alb
runtime: nodejs
description: Exemplo de EC2 + Security Group + ALB com Pulumi, estruturado para múltiplos ambientes (staging/prod)
config:
  environment:
    type: string
    description: Nome do ambiente; usado em prefixos e tags. Definido por cada stack.
  instanceType:
    type: string
    description: Tipo da instância EC2.
    default: t3.micro
  instanceCount:
    type: integer
    description: Quantas instâncias EC2 atrás do ALB.
    default: 1
  allowedCidrBlocks:
    type: array
    items:
      type: string
    description: CIDRs liberados para acessar o ALB na porta 80.
    default:
      - 0.0.0.0/0

```

```yml
#Pulumi.prod.yaml
config:
  aws:region: us-east-1
  pulumi-ec2-alb:environment: prod
  # prod sobrescreve os defaults: instância maior e mais réplicas.
  pulumi-ec2-alb:instanceType: t3.small
  pulumi-ec2-alb:instanceCount: 2
```

```yml
#Pulumi.staging.yaml
config:
  aws:region: us-east-1
  pulumi-ec2-alb:environment: staging
  # staging idêntico a prod, queremos o mais próximo possível.
  pulumi-ec2-alb:instanceType: t3.small
  pulumi-ec2-alb:instanceCount: 2

```

E se quiséssemos subir um ambiente de **homologação**, reduzido, somente para testes de features? Basta um ``pulumi stack init homolog`` e ajustar o arquivo de configuração conforme o estado desejado

```yml
#Pulumi.homolog.yaml
config:
  aws:region: us-east-1
  # homolog herda quase tudo dos defaults do Pulumi.yaml
  # (instanceType=t3.micro, instanceCount=1, allowedCidrBlocks=0.0.0.0/0).
  # Só precisamos identificar o ambiente:
  pulumi-ec2-alb:environment: homolog

```

Tudo isso para rodar nesse único entrypoint.

```typescript

const servers: aws.ec2.Instance[] = [];
for (let i = 0; i < instanceCount; i++) {
    servers.push(new aws.ec2.Instance(`${prefix}-web-${i}`, {
        ami: ami.id,
        instanceType: instanceType,
        subnetId: subnets.ids.apply(ids => ids[i % ids.length]),
        vpcSecurityGroupIds: [ec2Sg.id],
        userData: userData,
        tags: { ...commonTags, Name: `${prefix}-web-${i}` },
    }));
}

```

### Pra fechar

Esse setup inicial parece bem simples né? E realmente é, mas ainda sim tem algumas armadilhas e cuidados que devemos tomar pensando em escala e ambientes reais. A complexidade vai entrando conforme vamos escalando e queremos manter nossa IaC como fonte da verdade inclusive do runtime da nossa aplicação, o que é bem comum em aplicações com ECS por exemplo, onde começamos a separar as stacks não só por ambiente mas também entre o que é "volátil" e o que é "estável", aqui definimos até qual a tag da imagem docker rodando atualmente na aplicação, e não podemos que updates de imagem travem ou afetem updates no restante da infraestrutura, vide o que é volátil e o que é estável.

### Precisa de ajuda?

Sente que precisa de ajuda pra estruturar a sua própria infraestrutura ou algo do que eu falei aqui faz sentido pra você mas sente que é muito complicado fazer por conta? Aqui na [UEEK](https://ueek.digital/) a gente fornece esse tipo de consultoria pra facilitar sua estruturação de DevOps, desde infraestrutura até CI/CD, segurança e observabilidade. [Clica aqui](https://consultorias.ueek.digital/diagnostico-devsecops) e confere gratuitamente!


---

# posts/pt/porque-precisamos-de-um-ambiente-de-staging.mdx

Source: posts/pt/porque-precisamos-de-um-ambiente-de-staging.mdx


---
title: Porquê precisamos de um ambiente de staging
description: "Manter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?"
category: DevOps
publishedAt: 2026-06-24
tags:
  - staging
  - environments
  - devops
  - reliability
  - cost
  - testing
author:
  name: Luck Ramos
  role: Tech Lead
  avatar: /authors/luckramos.jpeg
featured: true
draft: false
readingTime: 5
translationKey: staging-environment
---


import CRTFrame from '~/components/post/CRTFrame.astro';

<CRTFrame
     src="/posts/porque-ambiente-staging/banner.png"
     alt="Ilustração de um palco em preto e branco"
     caption="FIG.1 · ambiente de Staging"
/>

É comum encontrar se aventurando por aí, empresas que batem o pé quando o assunto é criar ambientes de **staging** propriamente ditos alegando uma economia nos custos de infraestrutura. Essas mesmas empresas eventualmente esbarram em incidentes críticos em **produção** que quase que via de regra acabam custando muito mais do que o dito ambiente de **staging**. Hoje vamos discorrer o que realmente é um ambiente de staging, quais propósitos ele cumpre e estratégias para mitigar o custo de infraestrutura ao manter um.

### Conceito

O nome "staging" é o teste final antes de produção, vem de "stage testing", e são os ajustes finais no cenário mais próximo da realidade no palco, antes da apresentação. Com isso, implica-se que **o ambiente de staging tem que ser sempre o mais próximo possível de production**, e quando falamos "mais próximo possível" é realmente em sua completude, não somente as features da aplicação, mas a topologia de rede, regras de segurança, scaling, bancos de dados, compute, tratamento de erros, alertas de observabilidade, autenticação, capacidade e tudo que se tem direito. Se vai existir em production, deve existir também em staging.

### Custo do risco

Sabendo o que é (ou deveria ser) um ambiente de staging propriamente dito, fica muito mais fácil entender quais as consequências e riscos que aceitamos assumir quando escolhemos não manter um ambiente de staging no nosso fluxo de entrega. Aceitamos que estamos suscetíveis a todas e quaisquer potenciais falhas que não sejam de aplicação (isso considerando que pelo menos as features da aplicação foram testadas previamente). É aceitar que um alerta de observabilidade pode não disparar. É aceitar que o banco de dados pode estourar a capacidade de conexões ativas em um pico de acesso. É aceitar que seu servidor pode não aguentar alguma operação pesada da sua aplicação. É aceitar que pode existir uma brecha de segurança em alguma camada que não foi testada e conferida antes e agora o que está exposto são os seus usuários. É sempre mais barato não ter um ambiente de staging até o momento que uma dessas bombas exploda. 

Além de ter um ambiente de staging, ele precisa cumprir seu propósito por completo. Não basta ter uma **"homologação tunada"**, um ambiente com compute reduzido, dados distantes da realidade, topologia de rede alterada ou sem o volume de tráfego de produção Quer alguns exemplos de como um ambiente de staging bem azeitado faz falta?

- Cloudflare - [Cloudflare outage on February 20, 2026](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)
- Gitlab - [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)
- Roblox - [Roblox Return to Service \| Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021)

### Como minimizar os custos de infra?

Mesmo demonstrando que é muito mais barato manter um ambiente de staging do que correr os riscos do contrário, para muitas empresas ainda pode ser um investimento caro, que reduz margem. É desejável, mas nem sempre é possível.

Para contornar isso, temos algumas estratégias que envolvem principalmente efemeridade, servidores e serviços sob demanda. Isso depende muito da realidade e maturidade de cada time de desenvolvimento, mas considerando fluxos de entregas a cada sprint (geralmente duas semanas), faz mesmo sentido mantermos os ambientes em idle gerando custos? A maioria dos serviços cloud hoje oferece recursos para interromper parcialmente serviços e reduzir custos. Puxando alguns exemplos da AWS, o Amazon Aurora recentemente passou a aceitar **minCapacity 0** o que interrompe os custos de compute quando não recebe mais conexões. EC2 tem o **start/stop**, ECS tem o **desiredCount**, S3 tem o **Glacier**. A regra aqui é provisionar somente sob demanda para cortar ao máximo os custos quando em idle. Utilizando **IaC**, a maioria dessas coisas podem até ser completamente derrubadas e reestabelecidas conforme a necessidade, se o **cold start** de algumas horas (a depender da escala) for aceitável pro fluxo do seu time.

### Para onde ir agora?

Apesar de tudo isso que eu falei aqui, é muito, muito comum mesmo empresas e times que aplicam esses **multi-ambientes** de forma errada ou subótima, e é um problema que eu tenho certeza que até quem faz certo hoje já enfrentou antes. A gente só aprende mesmo depois de sofrer com a cagada de não ter feito mais cedo.

Aqui na [UEEK](https://ueek.digital/) mesmo a gente já sofreu muito por não ter ambiente de testes antes, ou não ter uma réplica fiel de produção para testar toda a operação de ponta a ponta e encontrar os problemas antes que chegassem nos clientes, e a gente aprendeu tanto com esse tipo de problema que hoje a gente consegue oferecer uma ajudinha pra quem não quer passar pelo mesmo que a gente. Se interessou? [Clica aqui e dá uma olhada, é grátis!](https://consultorias.ueek.digital/diagnostico-devsecops)


---

## About This Document

This concatenated documentation file is generated automatically by aeo.js
to make it easier for AI systems to understand the complete context of this project.

For a structured index, see: https://blog.luckramos.com/llms.txt
For individual files, see: https://blog.luckramos.com/docs.json

Generated by aeo.js - https://aeojs.org