{ "version": "1.0", "generated": "2026-07-01T19:47:06.966Z", "site": { "title": "Luck Goes to Cloud", "description": "Sobre arquitetura, cloud, devops, desenvolvimento e os processos do que eu construo no meu dia a dia.", "url": "https://blog.luckramos.com" }, "entries": [ { "id": "01ef6a6e36cc89d0", "url": "https://blog.luckramos.com/en/posts/why-we-need-a-staging-environment", "title": "Why we need a staging environment · Luck Goes to Cloud (Part 1)", "content": "[← back to /blog](/en/posts)\n\n##### ── META\n\ncat: **devops****\nread: 5 min\n\nwords: 622\n\ndate: 2026-06-24\n\nissue: 01.05**\n\n##### ── AUTHOR\n\nLuck Ramos\n\nTech Lead\n\n##### ── SHARE\n\n[↗ 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&body=https%3A%2F%2Fblog.luckramos.com%2Fen%2Fposts%2Fwhy-we-need-a-staging-environment%2F)\n\n##### ── FILED UNDER\n\n[#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)\n\n● DEVOPS 01.05 Jun 24, 2026 5 min\n\n## Why we need a staging environment\n\nDoes keeping a replica of the production environment really matter? What does it get you?\n\nFIG.1 · staging environment\n\nIt’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.\n\n## The concept", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "keywords": [ "staging", "environment", "that", "posts", "https", "costs", "production", "accepting", "cost", "what" ], "metadata": { "chunkIndex": 0, "totalChunks": 3, "sourcePath": "/en/posts/why-we-need-a-staging-environment" } }, { "id": "0a96ddaad5fdf640", "url": "https://blog.luckramos.com/pt/posts/tag/cost", "title": "#cost · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:cost limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts com a tag #cost no Luck Goes to Cloud.", "keywords": [ "mais", "2026", "mmxxvi", "devops", "cost", "staging", "feed", "posts", "search", "catalog" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/cost" } }, { "id": "17f92700ca406006", "url": "https://blog.luckramos.com/en/about", "title": "/about · who am I? · Luck Goes to Cloud", "content": "$ whoami --verbose --since=2026\n\n/about · the colophon · {aboutIssue}\n\n--> 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.\n\nI'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!\n\n[BROWSE THE POSTS →](/en/posts) [SAY HELLO](mailto:lukcramos@gmail.com)\n\n── §02 · CHANNELS\n\n## Where to find me\n\n[01 $ git clone @luckramos ↗](https://github.com/luckramos)\n\n[02 $ curl -L in/lukcramos ↗](https://www.linkedin.com/in/lukcramos)\n\n[03 $ ssh -p 443 @lukcramos ↗](https://x.com/lukcramos)\n\n[04 $ curl -L UEEK ↗](https://ueek.digital)\n\n[05 $ echo | sendmail lukcramos@gmail.com ↗](mailto:lukcramos@gmail.com)\n\n[06 $ tail -f /en/rss.xml ↗](/en/rss.xml)\n\n── §03 · COLOPHON\n\n## How is the blog made?\n\ntypeface (display)\n\nSpace Grotesk\n\ntypeface (mono)\n\nJetBrains Mono\n\naccent (dark)\n\n#00FF41 · phosphor P1\n\naccent (light)\n\n#CC5500 · phosphor P3\n\nbuilt with\n\nAstro · React · MDX\n\nFound a typo? A logic error? A take you'd argue with at the bar? [Tell me](mailto:lukcramos@gmail.com)", "description": "Who runs Luck Goes to Cloud and how to reach me.", "keywords": [ "lukcramos", "gmail", "https", "ueek", "find", "i've", "been", "mailto", "since", "about" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/about" } }, { "id": "1c3ac357722de06b", "url": "https://blog.luckramos.com/pt/posts/estruturando-iac-multi-ambiente", "title": "Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes · Luck Goes to Cloud (Part 4)", "content": "#Pulumi.prod.yaml\nconfig:\naws:region: us-east-1\npulumi-ec2-alb:environment: prod\n# prod sobrescreve os defaults: instância maior e mais réplicas.\npulumi-ec2-alb:instanceType: t3.small\npulumi-ec2-alb:instanceCount: 2\n#Pulumi.staging.yaml\nconfig:\naws:region: us-east-1\npulumi-ec2-alb:environment: staging\n# staging idêntico a prod, queremos o mais próximo possível.\npulumi-ec2-alb:instanceType: t3.small\npulumi-ec2-alb:instanceCount: 2\n\nE 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\n\n#Pulumi.homolog.yaml\nconfig:\naws:region: us-east-1\n# homolog herda quase tudo dos defaults do Pulumi.yaml\n# (instanceType=t3.micro, instanceCount=1, allowedCidrBlocks=0.0.0.0/0).\n# Só precisamos identificar o ambiente:\npulumi-ec2-alb:environment: homolog\n\nTudo isso para rodar nesse único entrypoint.\n\nconst servers: aws.ec2.Instance[] = [];\nfor (let i = 0; i < instanceCount; i++) {\nservers.push(new aws.ec2.Instance(`${prefix}-web-${i}`, {\nami: ami.id,\ninstanceType: instanceType,\nsubnetId: subnets.ids.apply(ids => ids[i % ids.length]),\nvpcSecurityGroupIds: [ec2Sg.id],\nuserData: userData,\ntags: { ...commonTags, Name: `${prefix}-web-${i}` },\n}));\n}\n\n## Pra fechar\n\nEsse 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.", "description": "Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível", "keywords": [ "como", "ambiente", "para", "pulumi", "ambientes", "config", "aqui", "staging", "posts", "infraestrutura" ], "metadata": { "chunkIndex": 3, "totalChunks": 5, "sourcePath": "/pt/posts/estruturando-iac-multi-ambiente" } }, { "id": "23d43be6906b26ff", "url": "https://blog.luckramos.com/en/posts/tag/pulumi", "title": "#pulumi · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:tag:pulumi clear all\n\n[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)\n\nper page122436100", "description": "Posts tagged #pulumi from Luck Goes to Cloud.", "keywords": [ "pulumi", "2026", "mmxxvi", "environments", "first", "feed", "posts", "search", "catalog", "01all" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/pulumi" } }, { "id": "25596d485e791b36", "url": "https://blog.luckramos.com/rss.xml", "title": "Redirecting to: /en/rss.xml", "content": "Redirecting to: /en/rss.xml [Redirecting from /rss.xml/ to /en/rss.xml](/en/rss.xml)", "keywords": [ "redirecting", "from" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/rss.xml" } }, { "id": "2da590873aa1cf9c", "url": "https://blog.luckramos.com/pt/posts/tag/iac", "title": "#iac · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:iac limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts com a tag #iac no Luck Goes to Cloud.", "keywords": [ "mais", "2026", "mmxxvi", "pulumi", "feed", "posts", "search", "catalog", "01todos", "posts00202devops00103infraestrutura001" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/iac" } }, { "id": "3775b7669bf37174", "url": "https://blog.luckramos.com/en/posts/tag/environments", "title": "#environments · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 2\n\nshowing 1–2 of 2\n\nupdated 19:47 UTC\n\nactive filters:tag:environments clear all\n\n[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)\n\n[DEVOPS 01.05 Why we need a staging environment Luck Ramos Jun 24, 2026 · 5 min](/en/posts/why-we-need-a-staging-environment)\n\nper page122436100", "description": "Posts tagged #environments from Luck Goes to Cloud.", "keywords": [ "2026", "environments", "posts", "mmxxvi", "devops", "pulumi", "staging", "first", "luck", "feed" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/environments" } }, { "id": "38363d641af1ce4a", "url": "https://blog.luckramos.com/en/404", "title": "404 · signal lost · Luck Goes to Cloud", "content": "── ERR · 404 · NOT_IN_INDEX\n\n## 404\n\nThe page you tried to reach is not in the archive. The signal got lost between the terminal and the cloud.\n\n[BACK TO HOME →](/en) [BROWSE THE ARCHIVE](/en/posts)", "description": "The page you tried to reach is not in the archive. The signal got lost between the terminal and the cloud.", "keywords": [ "archive", "index", "page", "tried", "reach", "signal", "lost", "between", "terminal", "cloud" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/404" } }, { "id": "3c570e5560676896", "url": "https://blog.luckramos.com/posts/en/why-we-need-a-staging-environment", "title": "Why we need a staging environment (Part 3)", "content": "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.", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "keywords": [ "staging", "environment", "that", "it's", "costs", "accepting", "from", "when", "production", "this" ], "metadata": { "title": "Why we need a staging environment", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "category": "DevOps", "publishedAt": "2026-06-24", "tags": "", "author": "", "name": "Luck Ramos", "role": "Tech Lead", "avatar": "/authors/luckramos.jpeg", "featured": "true", "draft": "false", "readingTime": "5", "translationKey": "staging-environment", "chunkIndex": 2, "totalChunks": 3, "sourcePath": "posts/en/why-we-need-a-staging-environment.mdx" } }, { "id": "3d26a7e74169952d", "url": "https://blog.luckramos.com/pt/404", "title": "404 · sinal perdido · Luck Goes to Cloud", "content": "── ERR · 404 · NAO_NO_INDICE\n\n## 404\n\nA página que você tentou acessar não está no arquivo. O sinal se perdeu entre o terminal e a nuvem.\n\n[VOLTAR PARA O INÍCIO →](/pt) [EXPLORAR O ARQUIVO](/pt/posts)", "description": "A página que você tentou acessar não está no arquivo. O sinal se perdeu entre o terminal e a nuvem.", "keywords": [ "arquivo", "indice", "página", "você", "tentou", "acessar", "não", "está", "sinal", "perdeu" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/404" } }, { "id": "3efd0b29fcd8d6bc", "url": "https://blog.luckramos.com/posts/pt/estruturando-iac-multi-ambiente", "title": "Por que múltiplos ambientes? (Part 4)", "content": "```yml\n#Pulumi.homolog.yaml\nconfig:\n aws:region: us-east-1\n # homolog herda quase tudo dos defaults do Pulumi.yaml\n # (instanceType=t3.micro, instanceCount=1, allowedCidrBlocks=0.0.0.0/0).\n # Só precisamos identificar o ambiente:\n pulumi-ec2-alb:environment: homolog\n\n```\n\nTudo isso para rodar nesse único entrypoint.\n\n```typescript\n\nconst servers: aws.ec2.Instance[] = [];\nfor (let i = 0; i < instanceCount; i++) {\n servers.push(new aws.ec2.Instance(`${prefix}-web-${i}`, {\n ami: ami.id,\n instanceType: instanceType,\n subnetId: subnets.ids.apply(ids => ids[i % ids.length]),\n vpcSecurityGroupIds: [ec2Sg.id],\n userData: userData,\n tags: { ...commonTags, Name: `${prefix}-web-${i}` },\n }));\n}\n\n```\n\n## Pra fechar\n\nEsse 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.\n\n## Precisa de ajuda?\n\nSente 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!", "keywords": [ "ambiente", "pulumi", "como", "para", "ambientes", "config", "aqui", "staging", "instancetype", "pulumi-ec2-alb" ], "metadata": { "chunkIndex": 3, "totalChunks": 4, "sourcePath": "posts/pt/estruturando-iac-multi-ambiente.mdx" } }, { "id": "41f476bb8d451205", "url": "https://blog.luckramos.com/posts/pt/estruturando-iac-multi-ambiente", "title": "Por que múltiplos ambientes? (Part 2)", "content": "**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.\n\n**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.\n\n**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.\n\n**Produção**: Ambiente final, clientes acessam.\n\nA 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.\n\n## Estrutura IaC para suportar múltiplos ambientes\n\nVou usar aqui o **Pulumi** para exemplo, mas todos os conceitos aqui discutidos podem ser aplicados em outras ferramentas como **Terraform**.\n\nUm dos conceitos mais difundidos aqui é que uma **stack** *(workspace no caso do Terraform)* equivale sempre a um **ambiente**. Considere o seguinte.\n\nNó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..yaml``. Considere o primeiro como os \"defaults\" e o segundo como o override dinâmico por stack.\n\n```typescript\nconst config = new pulumi.Config();", "keywords": [ "ambiente", "pulumi", "como", "para", "ambientes", "config", "aqui", "staging", "instancetype", "pulumi-ec2-alb" ], "metadata": { "chunkIndex": 1, "totalChunks": 4, "sourcePath": "posts/pt/estruturando-iac-multi-ambiente.mdx" } }, { "id": "449c17f3c8d73115", "url": "https://blog.luckramos.com/pt/posts/tag/terraform", "title": "#terraform · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:terraform limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts com a tag #terraform no Luck Goes to Cloud.", "keywords": [ "mais", "2026", "mmxxvi", "pulumi", "terraform", "feed", "posts", "search", "catalog", "01todos" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/terraform" } }, { "id": "4b0ffa0a003b4b02", "url": "https://blog.luckramos.com/en/posts/why-we-need-a-staging-environment", "title": "Why we need a staging environment · Luck Goes to Cloud (Part 2)", "content": "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.\n\n## The cost of risk\n\nKnowing 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.\n\nBeyond 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?\n\n- Cloudflare - [Cloudflare outage on February 20, 2026](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "keywords": [ "staging", "environment", "that", "posts", "https", "costs", "production", "accepting", "cost", "what" ], "metadata": { "chunkIndex": 1, "totalChunks": 3, "sourcePath": "/en/posts/why-we-need-a-staging-environment" } }, { "id": "4b71c09c5a40ab2a", "url": "https://blog.luckramos.com/pt/posts/category/Infraestrutura", "title": "Infraestrutura · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Infraestrutura · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:cat:infraestrutura limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts na categoria Infraestrutura no Luck Goes to Cloud.", "keywords": [ "mais", "infraestrutura", "2026", "mmxxvi", "pulumi", "feed", "search", "catalog", "01todos", "posts00202devops00103infraestrutura001" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/category/Infraestrutura" } }, { "id": "515376ebbdc0f810", "url": "https://blog.luckramos.com/posts/pt/estruturando-iac-multi-ambiente", "title": "Por que múltiplos ambientes? (Part 1)", "content": "---\ntitle: Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes\ndescription: \"Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível\"\ncategory: Infraestrutura\npublishedAt: 2026-07-01\ntags:\n - iac\n - pulumi\n - terraform\n - aws\n - devops\n - environments\nauthor:\n name: Luck Ramos\n role: Tech Lead\n avatar: /authors/luckramos.jpeg\nfeatured: true\ndraft: false\nreadingTime: 4\ntranslationKey: iac-multi-environment\n---\n\nimport CRTFrame from '~/components/post/CRTFrame.astro';\n\n\n\nAcho 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.\n\n**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.\n\n## Por que múltiplos ambientes?\n\nSoftware é 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.", "keywords": [ "ambiente", "pulumi", "como", "para", "ambientes", "config", "aqui", "staging", "instancetype", "pulumi-ec2-alb" ], "metadata": { "chunkIndex": 0, "totalChunks": 4, "sourcePath": "posts/pt/estruturando-iac-multi-ambiente.mdx" } }, { "id": "51cf4c531d6f2a40", "url": "https://blog.luckramos.com/posts", "title": "Redirecting to: /en/posts", "content": "Redirecting to: /en/posts [Redirecting from /posts/ to /en/posts](/en/posts)", "keywords": [ "posts", "redirecting", "from" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/posts" } }, { "id": "54c2199b170df9c0", "url": "https://blog.luckramos.com/posts/pt/porque-precisamos-de-um-ambiente-de-staging", "title": "Conceito (Part 2)", "content": "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. \n\nAlé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?\n\n- Cloudflare - [Cloudflare outage on February 20, 2026](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)\n- Gitlab - [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)\n- Roblox - [Roblox Return to Service \\| Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021)\n\n## Como minimizar os custos de infra?\n\nMesmo 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.", "keywords": [ "staging", "ambiente", "não", "mais", "muito", "para", "isso", "pode", "custos", "antes" ], "metadata": { "chunkIndex": 1, "totalChunks": 3, "sourcePath": "posts/pt/porque-precisamos-de-um-ambiente-de-staging.mdx" } }, { "id": "5b8faad74db82351", "url": "https://blog.luckramos.com/pt/posts/estruturando-iac-multi-ambiente", "title": "Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes · Luck Goes to Cloud (Part 1)", "content": "[← voltar para /blog](/pt/posts)\n\n##### ── META\n\ncat: **infraestrutura****\nread: 4 min\n\nwords: 958\n\ndate: 2026-07-01\n\nissue: 01.04**\n\n##### ── AUTHOR\n\n*\n\nLuck Ramos\n\nTech Lead\n\n##### ── SHARE\n\n[↗ 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&body=https%3A%2F%2Fblog.luckramos.com%2Fpt%2Fposts%2Festruturando-iac-multi-ambiente%2F)\n\n##### ── FILED UNDER\n\n[#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)\n\n● INFRAESTRUTURA 01.04 01 de jul. de 2026 4 min\n\n## Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes\n\nAmbientes comuns e como estruturar a criação deles em um único projeto reprodutível\n\nFIG.1 · diagrama IaC\n\nAcho 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.", "description": "Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível", "keywords": [ "como", "ambiente", "para", "pulumi", "ambientes", "config", "aqui", "staging", "posts", "infraestrutura" ], "metadata": { "chunkIndex": 0, "totalChunks": 5, "sourcePath": "/pt/posts/estruturando-iac-multi-ambiente" } }, { "id": "5fe3a1d977b18144", "url": "https://blog.luckramos.com/en/posts/structuring-iac-multi-environment", "title": "How to structure a Pulumi IaC project for multiple environments · Luck Goes to Cloud (Part 4)", "content": "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.\n\n#Pulumi.qa.yaml\nconfig:\naws:region: us-east-1\n# qa inherits almost everything from the Pulumi.yaml defaults\n# (instanceType=t3.micro, instanceCount=1, allowedCidrBlocks=0.0.0.0/0).\n# We only need to identify the environment:\npulumi-ec2-alb:environment: qa\n\nAll of it runs through this single entry point.\n\nconst servers: aws.ec2.Instance[] = [];\nfor (let i = 0; i < instanceCount; i++) {\nservers.push(new aws.ec2.Instance(`${prefix}-web-${i}`, {\nami: ami.id,\ninstanceType: instanceType,\nsubnetId: subnets.ids.apply(ids => ids[i % ids.length]),\nvpcSecurityGroupIds: [ec2Sg.id],\nuserData: userData,\ntags: { ...commonTags, Name: `${prefix}-web-${i}` },\n}));\n}\n\n## Wrapping up\n\nThis 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.\n\n[← back to /blog](/en/posts) END · 01.04\n\n##### ── ON THIS PAGE\n\n01Why multiple environments?02IaC structure to support multiple environments03Wrapping up\n\n[READ NEXT → Why we need a staging environment Luck Ramos · 5 min](/en/posts/why-we-need-a-staging-environment)", "description": "Multiple environments and how to structure them in a single reproducible project", "keywords": [ "environment", "pulumi", "environments", "config", "staging", "posts", "multiple", "that", "instancetype", "pulumi-ec2-alb" ], "metadata": { "chunkIndex": 3, "totalChunks": 4, "sourcePath": "/en/posts/structuring-iac-multi-environment" } }, { "id": "6e452dd355292d1d", "url": "https://blog.luckramos.com/about", "title": "Redirecting to: /en/about", "content": "Redirecting to: /en/about [Redirecting from /about/ to /en/about](/en/about)", "keywords": [ "about", "redirecting", "from" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/about" } }, { "id": "6f6963a473709c35", "url": "https://blog.luckramos.com/posts/en/structuring-iac-multi-environment", "title": "How to structure a Pulumi IaC project for multiple environments (Part 2)", "content": "**Production**: The final environment, where clients access.\n\nThe 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.\n\n## IaC structure to support multiple environments\n\nI'll use **Pulumi** here for the example, but all the concepts discussed here can be applied to other tools like **Terraform**.\n\nOne of the most widespread concepts here is that a **stack** *(a workspace in Terraform's case)* always maps to one **environment**. Consider the following.\n\nWe 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..yaml``. Think of the first as the \"defaults\" and the second as the dynamic per-stack override.\n\n```typescript\nconst config = new pulumi.Config();\n\nconst environment = config.require(\"environment\");\nconst instanceType = config.require(\"instanceType\");\nconst instanceCount = config.requireNumber(\"instanceCount\");\nconst allowedCidrBlocks = config.requireObject(\"allowedCidrBlocks\");\n```\n\nThis 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**.", "description": "Multiple environments and how to structure them in a single reproducible project", "keywords": [ "environment", "pulumi", "config", "that", "staging", "instancetype", "pulumi-ec2-alb", "environments", "yaml", "instancecount" ], "metadata": { "title": "How to structure a Pulumi IaC project for multiple environments", "description": "Multiple environments and how to structure them in a single reproducible project", "category": "Infrastructure", "publishedAt": "2026-07-01", "tags": "", "author": "", "name": "Luck Ramos", "role": "Tech Lead", "avatar": "/authors/luckramos.jpeg", "featured": "true", "draft": "false", "readingTime": "4", "translationKey": "iac-multi-environment", "chunkIndex": 1, "totalChunks": 4, "sourcePath": "posts/en/structuring-iac-multi-environment.mdx" } }, { "id": "7bd00ec01e95334f", "url": "https://blog.luckramos.com/pt/posts/tag/devops", "title": "#devops · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 2\n\nmostrando 1–2 de 2\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:devops limpar tudo\n\n[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)\n\n[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)\n\npor página122436100", "description": "Posts com a tag #devops no Luck Goes to Cloud.", "keywords": [ "2026", "devops", "mais", "posts", "mmxxvi", "pulumi", "staging", "luck", "feed", "search" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/devops" } }, { "id": "7e64821b2153134f", "url": "https://blog.luckramos.com/en/posts/why-we-need-a-staging-environment", "title": "Why we need a staging environment · Luck Goes to Cloud (Part 3)", "content": "- Gitlab - [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)\n\n- Roblox - [Roblox Return to Service | Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021)\n\n## How to minimize infra costs?\n\nEven 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.\n\nTo 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.\n\n[← back to /blog](/en/posts) END · 01.05\n\n##### ── ON THIS PAGE\n\n01The concept02The cost of risk03How to minimize infra costs?\n\n[READ NEXT → How to structure a Pulumi IaC project for multiple environments Luck Ramos · 4 min](/en/posts/structuring-iac-multi-environment)", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "keywords": [ "staging", "environment", "that", "posts", "https", "costs", "production", "accepting", "cost", "what" ], "metadata": { "chunkIndex": 2, "totalChunks": 3, "sourcePath": "/en/posts/why-we-need-a-staging-environment" } }, { "id": "80f59ce24e599df7", "url": "https://blog.luckramos.com/en/posts/tag/cost", "title": "#cost · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:tag:cost clear all\n\n[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)\n\nper page122436100", "description": "Posts tagged #cost from Luck Goes to Cloud.", "keywords": [ "2026", "mmxxvi", "devops", "cost", "staging", "first", "feed", "posts", "search", "catalog" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/cost" } }, { "id": "848760386f120bf4", "url": "https://blog.luckramos.com/en/posts/tag/devops", "title": "#devops · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 2\n\nshowing 1–2 of 2\n\nupdated 19:47 UTC\n\nactive filters:tag:devops clear all\n\n[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)\n\n[DEVOPS 01.05 Why we need a staging environment Luck Ramos Jun 24, 2026 · 5 min](/en/posts/why-we-need-a-staging-environment)\n\nper page122436100", "description": "Posts tagged #devops from Luck Goes to Cloud.", "keywords": [ "2026", "devops", "posts", "mmxxvi", "environments", "pulumi", "staging", "first", "luck", "feed" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/devops" } }, { "id": "8559b80f70b22095", "url": "https://blog.luckramos.com/en/posts/tag/staging", "title": "#staging · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:tag:staging clear all\n\n[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)\n\nper page122436100", "description": "Posts tagged #staging from Luck Goes to Cloud.", "keywords": [ "staging", "2026", "mmxxvi", "devops", "first", "feed", "posts", "search", "catalog", "01all" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/staging" } }, { "id": "86344aba24aebe7d", "url": "https://blog.luckramos.com/pt/posts/estruturando-iac-multi-ambiente", "title": "Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes · Luck Goes to Cloud (Part 3)", "content": "Um dos conceitos mais difundidos aqui é que uma **stack** *(workspace no caso do Terraform)* equivale sempre a um **ambiente**. Considere o seguinte.\n\nNó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..yaml. Considere o primeiro como os “defaults” e o segundo como o override dinâmico por stack.\n\nconst config = new pulumi.Config();\n\nconst environment = config.require(\"environment\");\nconst instanceType = config.require(\"instanceType\");\nconst instanceCount = config.requireNumber(\"instanceCount\");\nconst allowedCidrBlocks = config.requireObject(\"allowedCidrBlocks\");\nIsso 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**.\n\n#Pulumi.yaml\nname: pulumi-ec2-alb\nruntime: nodejs\ndescription: Exemplo de EC2 + Security Group + ALB com Pulumi, estruturado para múltiplos ambientes (staging/prod)\nconfig:\nenvironment:\ntype: string\ndescription: Nome do ambiente; usado em prefixos e tags. Definido por cada stack.\ninstanceType:\ntype: string\ndescription: Tipo da instância EC2.\ndefault: t3.micro\ninstanceCount:\ntype: integer\ndescription: Quantas instâncias EC2 atrás do ALB.\ndefault: 1\nallowedCidrBlocks:\ntype: array\nitems:\ntype: string\ndescription: CIDRs liberados para acessar o ALB na porta 80.\ndefault:\n- 0.0.0.0/0", "description": "Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível", "keywords": [ "como", "ambiente", "para", "pulumi", "ambientes", "config", "aqui", "staging", "posts", "infraestrutura" ], "metadata": { "chunkIndex": 2, "totalChunks": 5, "sourcePath": "/pt/posts/estruturando-iac-multi-ambiente" } }, { "id": "88f3197a6e09c431", "url": "https://blog.luckramos.com/posts/pt/estruturando-iac-multi-ambiente", "title": "Por que múltiplos ambientes? (Part 3)", "content": "const environment = config.require(\"environment\");\nconst instanceType = config.require(\"instanceType\");\nconst instanceCount = config.requireNumber(\"instanceCount\");\nconst allowedCidrBlocks = config.requireObject(\"allowedCidrBlocks\");\n```\n\nIsso 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**.\n\n```yml\n#Pulumi.yaml\nname: pulumi-ec2-alb\nruntime: nodejs\ndescription: Exemplo de EC2 + Security Group + ALB com Pulumi, estruturado para múltiplos ambientes (staging/prod)\nconfig:\n environment:\n type: string\n description: Nome do ambiente; usado em prefixos e tags. Definido por cada stack.\n instanceType:\n type: string\n description: Tipo da instância EC2.\n default: t3.micro\n instanceCount:\n type: integer\n description: Quantas instâncias EC2 atrás do ALB.\n default: 1\n allowedCidrBlocks:\n type: array\n items:\n type: string\n description: CIDRs liberados para acessar o ALB na porta 80.\n default:\n - 0.0.0.0/0\n\n```\n\n```yml\n#Pulumi.prod.yaml\nconfig:\n aws:region: us-east-1\n pulumi-ec2-alb:environment: prod\n # prod sobrescreve os defaults: instância maior e mais réplicas.\n pulumi-ec2-alb:instanceType: t3.small\n pulumi-ec2-alb:instanceCount: 2\n```\n\n```yml\n#Pulumi.staging.yaml\nconfig:\n aws:region: us-east-1\n pulumi-ec2-alb:environment: staging\n # staging idêntico a prod, queremos o mais próximo possível.\n pulumi-ec2-alb:instanceType: t3.small\n pulumi-ec2-alb:instanceCount: 2\n\n```\n\nE 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", "keywords": [ "ambiente", "pulumi", "como", "para", "ambientes", "config", "aqui", "staging", "instancetype", "pulumi-ec2-alb" ], "metadata": { "chunkIndex": 2, "totalChunks": 4, "sourcePath": "posts/pt/estruturando-iac-multi-ambiente.mdx" } }, { "id": "8aba537679bab1c3", "url": "https://blog.luckramos.com/en/posts", "title": "/blog · the index · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 2\n\nshowing 1–2 of 2\n\nupdated 19:47 UTC\n\nactive filters:none\n\n[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)\n\n[DEVOPS 01.05 Why we need a staging environment Luck Ramos Jun 24, 2026 · 5 min](/en/posts/why-we-need-a-staging-environment)\n\nper page122436100", "description": "The complete list of posts on Luck Goes to Cloud — notes on architecture, cloud, system design and building systems.", "keywords": [ "2026", "posts", "mmxxvi", "devops", "environments", "pulumi", "staging", "first", "luck", "feed" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts" } }, { "id": "8bc8120e496a1abe", "url": "https://blog.luckramos.com/pt/posts/porque-precisamos-de-um-ambiente-de-staging", "title": "Porquê precisamos de um ambiente de staging · Luck Goes to Cloud (Part 3)", "content": "- Cloudflare - [Cloudflare outage on February 20, 2026](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)\n\n- Gitlab - [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)\n\n- Roblox - [Roblox Return to Service | Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021)\n\n## Como minimizar os custos de infra?\n\nMesmo 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.\n\nPara 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.\n\n## Para onde ir agora?", "description": "Manter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?", "keywords": [ "staging", "ambiente", "não", "para", "https", "posts", "mais", "custos", "muito", "20de" ], "metadata": { "chunkIndex": 2, "totalChunks": 4, "sourcePath": "/pt/posts/porque-precisamos-de-um-ambiente-de-staging" } }, { "id": "8de24755322d13bf", "url": "https://blog.luckramos.com/pt", "title": "Luck Goes to Cloud", "content": "VOL. I · NO. 01 MMXXVI · GENESIS\n\nEM DESTAQUE · INFRAESTRUTURA ·\n01.04\n\n## luck:*goes*:cloud.\n\n*Sobre arquitetura, cloud, devops, desenvolvimento e os processos do que eu construo no meu ***dia a dia.**\n\n[EXPLORAR OS POSTS→](/pt/posts) [LER O MAIS RECENTE](/pt/posts/estruturando-iac-multi-ambiente) 2 posts · est. ∞\n\n[01.06 · INFRAESTRUTURA Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes](/pt/posts/estruturando-iac-multi-ambiente)\n\n[01.07 · DEVOPS Porquê precisamos de um ambiente de staging](/pt/posts/porque-precisamos-de-um-ambiente-de-staging)\n\n.:=++***+=:.\n-#@@@@@@@@@@@@@@@@#-\n:%@@@@@@@@@%%%%%%%@@@@@@%-\n-@@@@@@@@@%%%%%%%%%%%%%%@@@@@=\n@@@@@@@@%%%%%%%%%%%%%%%%%%%%@@@@:\n.@@@@@@@@@@%%%%%%%%%%%%%%@@@@@@@%%@=\n.@@@@@%###@@@@@%%%%%%%%@@@@%**#%@@@@@+\n@@#- =@@@@@@@@@@- -*%@-\n. *%%@@@@%= *@@@@@@- +%@@@@@*:\n=@@@@*. =#@@- +@@#- .+@@@@\n@ %#@@ @@ @@ -- -@% @@ @@@% .@+\n.@- %@@@ *@ @@@@ -@+ @@@# +@*\n.@@ @@@* -@* :@@@@. %@- *@@@ %@*\n.@@% +@@@@%%@@- :@@@@@@. -@@%%@@@@+ %%@*\n@@@@- :-=- *@@@%%@@@* :--: -%##%*\n#@%%@@@#=-::-+%@@@@@@@@@@@@%*--:-=*%%%%*#%\n@@%%%%%@@@@@@@@@@@: .@%@@@@@@@@%%%#**%@:\n@@@%%%%%%%%%%%%%%%@=------=%%%%%%%%%%%%%#*#%@@=\n@@%%%#%%%%%%%%%%%%%%@@@@@@@@%%%%%%%%%%%%%#*#@@@@+\n@@@@%#*%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%####%#**%@@@@:\n*@@@@#++%%%%%%%%%%%%%%%%%%%%%%%%#%%%######%#=+#@@@@@\n-@@@%==*%%%%%%%%%%%%%%%%%%#%%#####%%#%%###%#*=+*@@@%\n:. #%%%%%%%%%%%%%%%%%%%#%%%%%%##%%#####%#*#: .-:\n@@%%%%%*#%%%%%%%%%%%#%%#####%%#+*#%%%**%-\n@@%%#%#**#%%####%%%%%%%#####%%***#%%%**@:\n#@%%%%#*##%%%%%%%%%##%%%%##%%#****%%#*#@\n=@%%%%#%%%%%%%%%%%*####%%%%%%##%%###**#%\n@@@@@#:.=@@%%%%%%%**#%%%%%%%%*-:+%%#%@+\n#%%+ %@@@@@* =%@%%%%- :#%%=\n:+*+: =*+-\n\nFIG.01 · 「ghost」\n\n722 frames @ 30fps\n\nrender · ascii · 130×38\n\nloop · 24.1s/cycle", "description": "Sobre arquitetura, cloud, devops, desenvolvimento e os processos do que eu construo no meu dia a dia.", "keywords": [ "posts", "infraestrutura", "cloud", "devops", "estruturando-iac-multi-ambiente", "mmxxvi", "genesis", "destaque", "luck", "goes" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt" } }, { "id": "922ffe425909a0e0", "url": "https://blog.luckramos.com/en/posts/structuring-iac-multi-environment", "title": "How to structure a Pulumi IaC project for multiple environments · Luck Goes to Cloud (Part 2)", "content": "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.\n\n**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.\n\n**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.\n\n**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.\n\n**Production**: The final environment, where clients access.\n\nThe 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.\n\n## IaC structure to support multiple environments\n\nI’ll use **Pulumi** here for the example, but all the concepts discussed here can be applied to other tools like **Terraform**.\n\nOne of the most widespread concepts here is that a **stack** *(a workspace in Terraform’s case)* always maps to one **environment**. Consider the following.", "description": "Multiple environments and how to structure them in a single reproducible project", "keywords": [ "environment", "pulumi", "environments", "config", "staging", "posts", "multiple", "that", "instancetype", "pulumi-ec2-alb" ], "metadata": { "chunkIndex": 1, "totalChunks": 4, "sourcePath": "/en/posts/structuring-iac-multi-environment" } }, { "id": "942fbb335be583a8", "url": "https://blog.luckramos.com/en/posts/tag/aws", "title": "#aws · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:tag:aws clear all\n\n[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)\n\nper page122436100", "description": "Posts tagged #aws from Luck Goes to Cloud.", "keywords": [ "2026", "mmxxvi", "environments", "pulumi", "first", "feed", "posts", "search", "catalog", "01all" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/aws" } }, { "id": "9986acf65eb0ba2b", "url": "https://blog.luckramos.com/pt/posts/porque-precisamos-de-um-ambiente-de-staging", "title": "Porquê precisamos de um ambiente de staging · Luck Goes to Cloud (Part 2)", "content": "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.\n\n## Custo do risco\n\nSabendo 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.\n\nAlé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?", "description": "Manter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?", "keywords": [ "staging", "ambiente", "não", "para", "https", "posts", "mais", "custos", "muito", "20de" ], "metadata": { "chunkIndex": 1, "totalChunks": 4, "sourcePath": "/pt/posts/porque-precisamos-de-um-ambiente-de-staging" } }, { "id": "9f348b4d73bb4b9b", "url": "https://blog.luckramos.com/pt/posts/porque-precisamos-de-um-ambiente-de-staging", "title": "Porquê precisamos de um ambiente de staging · Luck Goes to Cloud (Part 1)", "content": "[← voltar para /blog](/pt/posts)\n\n##### ── META\n\ncat: **devops****\nread: 5 min\n\nwords: 789\n\ndate: 2026-06-24\n\nissue: 01.05**\n\n##### ── AUTHOR\n\nLuck Ramos\n\nTech Lead\n\n##### ── SHARE\n\n[↗ 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&body=https%3A%2F%2Fblog.luckramos.com%2Fpt%2Fposts%2Fporque-precisamos-de-um-ambiente-de-staging%2F)\n\n##### ── FILED UNDER\n\n[#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)\n\n● DEVOPS 01.05 24 de jun. de 2026 5 min\n\n## Porquê precisamos de um ambiente de staging\n\nManter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?\n\nFIG.1 · ambiente de Staging\n\nÉ 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.\n\n## Conceito", "description": "Manter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?", "keywords": [ "staging", "ambiente", "não", "para", "https", "posts", "mais", "custos", "muito", "20de" ], "metadata": { "chunkIndex": 0, "totalChunks": 4, "sourcePath": "/pt/posts/porque-precisamos-de-um-ambiente-de-staging" } }, { "id": "9f578a50f234e69e", "url": "https://blog.luckramos.com/pt/posts/estruturando-iac-multi-ambiente", "title": "Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes · Luck Goes to Cloud (Part 2)", "content": "**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.\n\n## Por que múltiplos ambientes?\n\nSoftware é 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.\n\n**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.\n\n**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.\n\n**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.\n\n**Produção**: Ambiente final, clientes acessam.\n\nA 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.\n\n## Estrutura IaC para suportar múltiplos ambientes\n\nVou usar aqui o **Pulumi** para exemplo, mas todos os conceitos aqui discutidos podem ser aplicados em outras ferramentas como **Terraform**.", "description": "Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível", "keywords": [ "como", "ambiente", "para", "pulumi", "ambientes", "config", "aqui", "staging", "posts", "infraestrutura" ], "metadata": { "chunkIndex": 1, "totalChunks": 5, "sourcePath": "/pt/posts/estruturando-iac-multi-ambiente" } }, { "id": "a04f59ffeb9a804f", "url": "https://blog.luckramos.com/pt/posts/estruturando-iac-multi-ambiente", "title": "Como estruturar um projeto de IaC com Pulumi para múltiplos ambientes · Luck Goes to Cloud (Part 5)", "content": "## Precisa de ajuda?\n\nSente 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!\n\n[← voltar para /blog](/pt/posts) END · 01.04\n\n##### ── ON THIS PAGE\n\n01Por que múltiplos ambientes?02Estrutura IaC para suportar múltiplos ambientes03Pra fechar04Precisa de ajuda?\n\n[PRÓXIMA", "description": "Ambientes comuns e como estruturar a criação deles em um único projeto reprodutível", "keywords": [ "como", "ambiente", "para", "pulumi", "ambientes", "config", "aqui", "staging", "posts", "infraestrutura" ], "metadata": { "chunkIndex": 4, "totalChunks": 5, "sourcePath": "/pt/posts/estruturando-iac-multi-ambiente" } }, { "id": "a83ccd13d10f2251", "url": "https://blog.luckramos.com/pt/posts/tag/reliability", "title": "#reliability · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:reliability limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts com a tag #reliability no Luck Goes to Cloud.", "keywords": [ "mais", "2026", "mmxxvi", "devops", "reliability", "staging", "feed", "posts", "search", "catalog" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/reliability" } }, { "id": "b04eb615c53905f2", "url": "https://blog.luckramos.com/posts/pt/porque-precisamos-de-um-ambiente-de-staging", "title": "Conceito (Part 3)", "content": "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.\n\n## Para onde ir agora?\n\nApesar 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.\n\nAqui 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)", "keywords": [ "staging", "ambiente", "não", "mais", "muito", "para", "isso", "pode", "custos", "antes" ], "metadata": { "chunkIndex": 2, "totalChunks": 3, "sourcePath": "posts/pt/porque-precisamos-de-um-ambiente-de-staging.mdx" } }, { "id": "b0547442760cab22", "url": "https://blog.luckramos.com/en/posts/structuring-iac-multi-environment", "title": "How to structure a Pulumi IaC project for multiple environments · Luck Goes to Cloud (Part 1)", "content": "[← back to /blog](/en/posts)\n\n##### ── META\n\ncat: **infrastructure****\nread: 4 min\n\nwords: 897\n\ndate: 2026-07-01\n\nissue: 01.04**\n\n##### ── AUTHOR\n\n*\n\nLuck Ramos\n\nTech Lead\n\n##### ── SHARE\n\n[↗ 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)\n\n##### ── FILED UNDER\n\n[#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)\n\n● INFRASTRUCTURE 01.04 Jul 01, 2026 4 min\n\n## How to structure a Pulumi IaC project for multiple environments\n\nMultiple environments and how to structure them in a single reproducible project\n\nFIG.1 · IaC diagram\n\nI’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.\n\n**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.\n\n## Why multiple environments?", "description": "Multiple environments and how to structure them in a single reproducible project", "keywords": [ "environment", "pulumi", "environments", "config", "staging", "posts", "multiple", "that", "instancetype", "pulumi-ec2-alb" ], "metadata": { "chunkIndex": 0, "totalChunks": 4, "sourcePath": "/en/posts/structuring-iac-multi-environment" } }, { "id": "b3e3c6f35cb9736a", "url": "https://blog.luckramos.com/posts/en/why-we-need-a-staging-environment", "title": "Why we need a staging environment (Part 2)", "content": "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.\n\nBeyond 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?\n\n- Cloudflare - [Cloudflare outage on February 20, 2026](https://blog.cloudflare.com/cloudflare-outage-february-20-2026/)\n- Gitlab - [Postmortem of database outage of January 31](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/)\n- Roblox - [Roblox Return to Service \\| Roblox](https://about.roblox.com/newsroom/2022/01/roblox-return-to-service-10-28-10-31-2021)\n\n## How to minimize infra costs?\n\nEven 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.", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "keywords": [ "staging", "environment", "that", "it's", "costs", "accepting", "from", "when", "production", "this" ], "metadata": { "title": "Why we need a staging environment", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "category": "DevOps", "publishedAt": "2026-06-24", "tags": "", "author": "", "name": "Luck Ramos", "role": "Tech Lead", "avatar": "/authors/luckramos.jpeg", "featured": "true", "draft": "false", "readingTime": "5", "translationKey": "staging-environment", "chunkIndex": 1, "totalChunks": 3, "sourcePath": "posts/en/why-we-need-a-staging-environment.mdx" } }, { "id": "b95ca1c2b87989fc", "url": "https://blog.luckramos.com/en/posts/category/Infrastructure", "title": "Infrastructure · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Infrastructure · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:cat:infrastructure clear all\n\n[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)\n\nper page122436100", "description": "Posts in the Infrastructure category on Luck Goes to Cloud.", "keywords": [ "infrastructure", "2026", "mmxxvi", "environments", "pulumi", "first", "feed", "search", "catalog", "01all" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/category/Infrastructure" } }, { "id": "bac8fcf1b2672fe4", "url": "https://blog.luckramos.com/posts/pt/porque-precisamos-de-um-ambiente-de-staging", "title": "Conceito (Part 1)", "content": "---\ntitle: Porquê precisamos de um ambiente de staging\ndescription: \"Manter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?\"\ncategory: DevOps\npublishedAt: 2026-06-24\ntags:\n - staging\n - environments\n - devops\n - reliability\n - cost\n - testing\nauthor:\n name: Luck Ramos\n role: Tech Lead\n avatar: /authors/luckramos.jpeg\nfeatured: true\ndraft: false\nreadingTime: 5\ntranslationKey: staging-environment\n---\n\n\nimport CRTFrame from '~/components/post/CRTFrame.astro';\n\n\n\nÉ 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.\n\n## Conceito\n\nO 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.\n\n## Custo do risco", "keywords": [ "staging", "ambiente", "não", "mais", "muito", "para", "isso", "pode", "custos", "antes" ], "metadata": { "chunkIndex": 0, "totalChunks": 3, "sourcePath": "posts/pt/porque-precisamos-de-um-ambiente-de-staging.mdx" } }, { "id": "be8fb2b75327a56d", "url": "https://blog.luckramos.com/en/posts/category/DevOps", "title": "DevOps · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## DevOps · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:cat:devops clear all\n\n[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)\n\nper page122436100", "description": "Posts in the DevOps category on Luck Goes to Cloud.", "keywords": [ "devops", "2026", "mmxxvi", "staging", "first", "feed", "search", "catalog", "01all", "posts00202devops00103infrastructure001" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/category/DevOps" } }, { "id": "bfab3df8199498eb", "url": "https://blog.luckramos.com/pt/posts/tag/aws", "title": "#aws · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:aws limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts com a tag #aws no Luck Goes to Cloud.", "keywords": [ "mais", "2026", "mmxxvi", "pulumi", "feed", "posts", "search", "catalog", "01todos", "posts00202devops00103infraestrutura001" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/aws" } }, { "id": "bfacf7febaad46b3", "url": "https://blog.luckramos.com/pt/posts", "title": "/blog · o índice · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 2\n\nmostrando 1–2 de 2\n\natualizado 19:47 UTC\n\nfiltros ativos:nenhum\n\n[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)\n\n[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)\n\npor página122436100", "description": "Lista completa de posts do Luck Goes to Cloud, anotações sobre arquitetura, cloud, system design e desenvolvimento de sistemas.", "keywords": [ "2026", "mais", "posts", "mmxxvi", "devops", "pulumi", "staging", "luck", "feed", "search" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts" } }, { "id": "c027ab37973990e2", "url": "https://blog.luckramos.com/pt/posts/tag/testing", "title": "#testing · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:testing limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts com a tag #testing no Luck Goes to Cloud.", "keywords": [ "mais", "2026", "mmxxvi", "devops", "staging", "testing", "feed", "posts", "search", "catalog" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/testing" } }, { "id": "c14ab7049546c4e2", "url": "https://blog.luckramos.com/pt/posts/porque-precisamos-de-um-ambiente-de-staging", "title": "Porquê precisamos de um ambiente de staging · Luck Goes to Cloud (Part 4)", "content": "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.\n\nAqui 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)\n\n[← voltar para /blog](/pt/posts) END · 01.05\n\n##### ── ON THIS PAGE\n\n01Conceito02Custo do risco03Como minimizar os custos de infra?04Para onde ir agora?\n\n[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)", "description": "Manter uma réplica do ambiente de produção realmente importa? O que isso pode me trazer?", "keywords": [ "staging", "ambiente", "não", "para", "https", "posts", "mais", "custos", "muito", "20de" ], "metadata": { "chunkIndex": 3, "totalChunks": 4, "sourcePath": "/pt/posts/porque-precisamos-de-um-ambiente-de-staging" } }, { "id": "c6b1c1ce3a0253dd", "url": "https://blog.luckramos.com/pt/posts/tag/environments", "title": "#environments · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 2\n\nmostrando 1–2 de 2\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:environments limpar tudo\n\n[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)\n\n[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)\n\npor página122436100", "description": "Posts com a tag #environments no Luck Goes to Cloud.", "keywords": [ "2026", "mais", "posts", "mmxxvi", "devops", "environments", "pulumi", "staging", "luck", "feed" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/environments" } }, { "id": "c825f3ea1eb27ecf", "url": "https://blog.luckramos.com/posts/en/why-we-need-a-staging-environment", "title": "Why we need a staging environment (Part 1)", "content": "import CRTFrame from '~/components/post/CRTFrame.astro';\n\n\n\nIt'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.\n\n## The concept\n\nThe 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.\n\n## The cost of risk", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "keywords": [ "staging", "environment", "that", "it's", "costs", "accepting", "from", "when", "production", "this" ], "metadata": { "title": "Why we need a staging environment", "description": "Does keeping a replica of the production environment really matter? What does it get you?", "category": "DevOps", "publishedAt": "2026-06-24", "tags": "", "author": "", "name": "Luck Ramos", "role": "Tech Lead", "avatar": "/authors/luckramos.jpeg", "featured": "true", "draft": "false", "readingTime": "5", "translationKey": "staging-environment", "chunkIndex": 0, "totalChunks": 3, "sourcePath": "posts/en/why-we-need-a-staging-environment.mdx" } }, { "id": "cd3c9c8ac5ba8893", "url": "https://blog.luckramos.com/posts/en/structuring-iac-multi-environment", "title": "How to structure a Pulumi IaC project for multiple environments (Part 3)", "content": "```yml\n#Pulumi.yaml\nname: pulumi-ec2-alb\nruntime: nodejs\ndescription: EC2 + Security Group + ALB example with Pulumi, structured for multiple environments (staging/prod)\nconfig:\n environment:\n type: string\n description: Environment name; used in prefixes and tags. Defined per stack.\n instanceType:\n type: string\n description: EC2 instance type.\n default: t3.micro\n instanceCount:\n type: integer\n description: How many EC2 instances behind the ALB.\n default: 1\n allowedCidrBlocks:\n type: array\n items:\n type: string\n description: CIDRs allowed to reach the ALB on port 80.\n default:\n - 0.0.0.0/0\n\n```\n\n```yml\n#Pulumi.prod.yaml\nconfig:\n aws:region: us-east-1\n pulumi-ec2-alb:environment: prod\n # prod overrides the defaults: bigger instance and more replicas.\n pulumi-ec2-alb:instanceType: t3.small\n pulumi-ec2-alb:instanceCount: 2\n```\n\n```yml\n#Pulumi.staging.yaml\nconfig:\n aws:region: us-east-1\n pulumi-ec2-alb:environment: staging\n # staging identical to prod, we want it as close as possible.\n pulumi-ec2-alb:instanceType: t3.small\n pulumi-ec2-alb:instanceCount: 2\n\n```\n\nAnd 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.\n\n```yml\n#Pulumi.qa.yaml\nconfig:\n aws:region: us-east-1\n # qa inherits almost everything from the Pulumi.yaml defaults\n # (instanceType=t3.micro, instanceCount=1, allowedCidrBlocks=0.0.0.0/0).\n # We only need to identify the environment:\n pulumi-ec2-alb:environment: qa\n\n```\n\nAll of it runs through this single entry point.\n\n```typescript", "description": "Multiple environments and how to structure them in a single reproducible project", "keywords": [ "environment", "pulumi", "config", "that", "staging", "instancetype", "pulumi-ec2-alb", "environments", "yaml", "instancecount" ], "metadata": { "title": "How to structure a Pulumi IaC project for multiple environments", "description": "Multiple environments and how to structure them in a single reproducible project", "category": "Infrastructure", "publishedAt": "2026-07-01", "tags": "", "author": "", "name": "Luck Ramos", "role": "Tech Lead", "avatar": "/authors/luckramos.jpeg", "featured": "true", "draft": "false", "readingTime": "4", "translationKey": "iac-multi-environment", "chunkIndex": 2, "totalChunks": 4, "sourcePath": "posts/en/structuring-iac-multi-environment.mdx" } }, { "id": "ce62fd5756c35c19", "url": "https://blog.luckramos.com/en/posts/tag/terraform", "title": "#terraform · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:tag:terraform clear all\n\n[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)\n\nper page122436100", "description": "Posts tagged #terraform from Luck Goes to Cloud.", "keywords": [ "2026", "mmxxvi", "environments", "pulumi", "terraform", "first", "feed", "posts", "search", "catalog" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/terraform" } }, { "id": "d52e74839f7654f6", "url": "https://blog.luckramos.com/en", "title": "Luck Goes to Cloud", "content": "VOL. I · NO. 01 MMXXVI · GENESIS\n\nFEATURED · INFRASTRUCTURE ·\n01.04\n\n## luck:*goes*:cloud.\n\nMy notes *on architecture, cloud and devops, the problems I run into and the process behind what I build in my ***day to day.**\n\n[BROWSE THE POSTS→](/en/posts) [READ THE LATEST](/en/posts/structuring-iac-multi-environment) 2 posts · est. ∞\n\n[01.06 · INFRASTRUCTURE How to structure a Pulumi IaC project for multiple environments](/en/posts/structuring-iac-multi-environment)\n\n[01.07 · DEVOPS Why we need a staging environment](/en/posts/why-we-need-a-staging-environment)\n\n.:=++***+=:.\n-#@@@@@@@@@@@@@@@@#-\n:%@@@@@@@@@%%%%%%%@@@@@@%-\n-@@@@@@@@@%%%%%%%%%%%%%%@@@@@=\n@@@@@@@@%%%%%%%%%%%%%%%%%%%%@@@@:\n.@@@@@@@@@@%%%%%%%%%%%%%%@@@@@@@%%@=\n.@@@@@%###@@@@@%%%%%%%%@@@@%**#%@@@@@+\n@@#- =@@@@@@@@@@- -*%@-\n. *%%@@@@%= *@@@@@@- +%@@@@@*:\n=@@@@*. =#@@- +@@#- .+@@@@\n@ %#@@ @@ @@ -- -@% @@ @@@% .@+\n.@- %@@@ *@ @@@@ -@+ @@@# +@*\n.@@ @@@* -@* :@@@@. %@- *@@@ %@*\n.@@% +@@@@%%@@- :@@@@@@. -@@%%@@@@+ %%@*\n@@@@- :-=- *@@@%%@@@* :--: -%##%*\n#@%%@@@#=-::-+%@@@@@@@@@@@@%*--:-=*%%%%*#%\n@@%%%%%@@@@@@@@@@@: .@%@@@@@@@@%%%#**%@:\n@@@%%%%%%%%%%%%%%%@=------=%%%%%%%%%%%%%#*#%@@=\n@@%%%#%%%%%%%%%%%%%%@@@@@@@@%%%%%%%%%%%%%#*#@@@@+\n@@@@%#*%%%%%%%%%%%%%%%%%%%%%%%%%%%#%%####%#**%@@@@:\n*@@@@#++%%%%%%%%%%%%%%%%%%%%%%%%#%%%######%#=+#@@@@@\n-@@@%==*%%%%%%%%%%%%%%%%%%#%%#####%%#%%###%#*=+*@@@%\n:. #%%%%%%%%%%%%%%%%%%%#%%%%%%##%%#####%#*#: .-:\n@@%%%%%*#%%%%%%%%%%%#%%#####%%#+*#%%%**%-\n@@%%#%#**#%%####%%%%%%%#####%%***#%%%**@:\n#@%%%%#*##%%%%%%%%%##%%%%##%%#****%%#*#@\n=@%%%%#%%%%%%%%%%%*####%%%%%%##%%###**#%\n@@@@@#:.=@@%%%%%%%**#%%%%%%%%*-:+%%#%@+\n#%%+ %@@@@@* =%@%%%%- :#%%=\n:+*+: =*+-\n\nFIG.01 · 「ghost」\n\n722 frames @ 30fps\n\nrender · ascii · 130×38\n\nloop · 24.1s/cycle", "description": "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.", "keywords": [ "posts", "infrastructure", "cloud", "devops", "structuring-iac-multi-environment", "mmxxvi", "genesis", "featured", "luck", "goes" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en" } }, { "id": "ddd42068d36b4a7f", "url": "https://blog.luckramos.com/pt/about", "title": "/sobre · quem sou eu? · Luck Goes to Cloud", "content": "$ whoami --verbose --since=2026\n\n/about · the colophon · {aboutIssue}\n\n--> 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.\n\nTrabalho 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!\n\n[EXPLORAR OS POSTS →](/pt/posts) [MANDE UM ALÔ](mailto:lukcramos@gmail.com)\n\n── §02 · CANAIS\n\n## Onde me encontrar\n\n[01 $ git clone @luckramos ↗](https://github.com/luckramos)\n\n[02 $ curl -L in/lukcramos ↗](https://www.linkedin.com/in/lukcramos)\n\n[03 $ ssh -p 443 @lukcramos ↗](https://x.com/lukcramos)\n\n[04 $ curl -L UEEK ↗](https://ueek.digital)\n\n[05 $ echo | sendmail lukcramos@gmail.com ↗](mailto:lukcramos@gmail.com)\n\n[06 $ tail -f /pt/rss.xml ↗](/pt/rss.xml)\n\n── §03 · COLOPHON\n\n## Como o blog é feito?\n\ntypeface (display)\n\nSpace Grotesk\n\ntypeface (mono)\n\nJetBrains Mono\n\naccent (dark)\n\n#00FF41 · phosphor P1\n\naccent (light)\n\n#CC5500 · phosphor P3\n\nbuilt with\n\nAstro · React · MDX\n\nAchou um erro de português? Um problema de lógica? Uma opinião que você discordaria no bar? [Me conta](mailto:lukcramos@gmail.com)", "description": "Quem escreve e como falar comigo.", "keywords": [ "lukcramos", "gmail", "https", "trabalho", "ueek", "mailto", "colophon", "você", "encontrar", "problemas" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/about" } }, { "id": "e0ffa19718452b05", "url": "https://blog.luckramos.com/pt/posts/tag/pulumi", "title": "#pulumi · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:pulumi limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts com a tag #pulumi no Luck Goes to Cloud.", "keywords": [ "pulumi", "mais", "2026", "mmxxvi", "feed", "posts", "search", "catalog", "01todos", "posts00202devops00103infraestrutura001" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/pulumi" } }, { "id": "e1ce99daa5a0f1fa", "url": "https://blog.luckramos.com/en/posts/tag/reliability", "title": "#reliability · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:tag:reliability clear all\n\n[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)\n\nper page122436100", "description": "Posts tagged #reliability from Luck Goes to Cloud.", "keywords": [ "2026", "mmxxvi", "devops", "reliability", "staging", "first", "feed", "posts", "search", "catalog" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/reliability" } }, { "id": "e4a688da8592e5ca", "url": "https://blog.luckramos.com/posts/en/structuring-iac-multi-environment", "title": "How to structure a Pulumi IaC project for multiple environments (Part 4)", "content": "const servers: aws.ec2.Instance[] = [];\nfor (let i = 0; i < instanceCount; i++) {\n servers.push(new aws.ec2.Instance(`${prefix}-web-${i}`, {\n ami: ami.id,\n instanceType: instanceType,\n subnetId: subnets.ids.apply(ids => ids[i % ids.length]),\n vpcSecurityGroupIds: [ec2Sg.id],\n userData: userData,\n tags: { ...commonTags, Name: `${prefix}-web-${i}` },\n }));\n}\n\n```\n\n## Wrapping up\n\nThis 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.", "description": "Multiple environments and how to structure them in a single reproducible project", "keywords": [ "environment", "pulumi", "config", "that", "staging", "instancetype", "pulumi-ec2-alb", "environments", "yaml", "instancecount" ], "metadata": { "title": "How to structure a Pulumi IaC project for multiple environments", "description": "Multiple environments and how to structure them in a single reproducible project", "category": "Infrastructure", "publishedAt": "2026-07-01", "tags": "", "author": "", "name": "Luck Ramos", "role": "Tech Lead", "avatar": "/authors/luckramos.jpeg", "featured": "true", "draft": "false", "readingTime": "4", "translationKey": "iac-multi-environment", "chunkIndex": 3, "totalChunks": 4, "sourcePath": "posts/en/structuring-iac-multi-environment.mdx" } }, { "id": "e61789496fc7d6af", "url": "https://blog.luckramos.com/posts/en/structuring-iac-multi-environment", "title": "How to structure a Pulumi IaC project for multiple environments (Part 1)", "content": "import CRTFrame from '~/components/post/CRTFrame.astro';\n\n\n\nI'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.\n\n**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.\n\n## Why multiple environments?\n\nSoftware 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.\n\n**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.\n\n**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.\n\n**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.", "description": "Multiple environments and how to structure them in a single reproducible project", "keywords": [ "environment", "pulumi", "config", "that", "staging", "instancetype", "pulumi-ec2-alb", "environments", "yaml", "instancecount" ], "metadata": { "title": "How to structure a Pulumi IaC project for multiple environments", "description": "Multiple environments and how to structure them in a single reproducible project", "category": "Infrastructure", "publishedAt": "2026-07-01", "tags": "", "author": "", "name": "Luck Ramos", "role": "Tech Lead", "avatar": "/authors/luckramos.jpeg", "featured": "true", "draft": "false", "readingTime": "4", "translationKey": "iac-multi-environment", "chunkIndex": 0, "totalChunks": 4, "sourcePath": "posts/en/structuring-iac-multi-environment.mdx" } }, { "id": "eaf8d1cae51b7472", "url": "https://blog.luckramos.com/en/posts/tag/testing", "title": "#testing · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:tag:testing clear all\n\n[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)\n\nper page122436100", "description": "Posts tagged #testing from Luck Goes to Cloud.", "keywords": [ "2026", "mmxxvi", "devops", "staging", "testing", "first", "feed", "posts", "search", "catalog" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/testing" } }, { "id": "ec1665c14422b72e", "url": "https://blog.luckramos.com/pt/posts/tag/staging", "title": "#staging · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## Todos os posts · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:tag:staging limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts com a tag #staging no Luck Goes to Cloud.", "keywords": [ "staging", "mais", "2026", "mmxxvi", "devops", "feed", "posts", "search", "catalog", "01todos" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/tag/staging" } }, { "id": "ec95bda44ee09d93", "url": "https://blog.luckramos.com/en/posts/structuring-iac-multi-environment", "title": "How to structure a Pulumi IaC project for multiple environments · Luck Goes to Cloud (Part 3)", "content": "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..yaml. Think of the first as the “defaults” and the second as the dynamic per-stack override.\n\nconst config = new pulumi.Config();\n\nconst environment = config.require(\"environment\");\nconst instanceType = config.require(\"instanceType\");\nconst instanceCount = config.requireNumber(\"instanceCount\");\nconst allowedCidrBlocks = config.requireObject(\"allowedCidrBlocks\");\nThis 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**.\n\n#Pulumi.yaml\nname: pulumi-ec2-alb\nruntime: nodejs\ndescription: EC2 + Security Group + ALB example with Pulumi, structured for multiple environments (staging/prod)\nconfig:\nenvironment:\ntype: string\ndescription: Environment name; used in prefixes and tags. Defined per stack.\ninstanceType:\ntype: string\ndescription: EC2 instance type.\ndefault: t3.micro\ninstanceCount:\ntype: integer\ndescription: How many EC2 instances behind the ALB.\ndefault: 1\nallowedCidrBlocks:\ntype: array\nitems:\ntype: string\ndescription: CIDRs allowed to reach the ALB on port 80.\ndefault:\n- 0.0.0.0/0\n\n#Pulumi.prod.yaml\nconfig:\naws:region: us-east-1\npulumi-ec2-alb:environment: prod\n# prod overrides the defaults: bigger instance and more replicas.\npulumi-ec2-alb:instanceType: t3.small\npulumi-ec2-alb:instanceCount: 2\n#Pulumi.staging.yaml\nconfig:\naws:region: us-east-1\npulumi-ec2-alb:environment: staging\n# staging identical to prod, we want it as close as possible.\npulumi-ec2-alb:instanceType: t3.small\npulumi-ec2-alb:instanceCount: 2", "description": "Multiple environments and how to structure them in a single reproducible project", "keywords": [ "environment", "pulumi", "environments", "config", "staging", "posts", "multiple", "that", "instancetype", "pulumi-ec2-alb" ], "metadata": { "chunkIndex": 2, "totalChunks": 4, "sourcePath": "/en/posts/structuring-iac-multi-environment" } }, { "id": "efff97cb2e904f19", "url": "https://blog.luckramos.com/en/posts/tag/iac", "title": "#iac · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01All posts00202DevOps00103Infrastructure001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸newest first▸oldest first▸longest reads▸random()\n\n$ luck --feed**Atom feed at [/en/rss.xml](/en/rss.xml).\n\n/blog · the index · MMXXVI\n\n## All posts · 1\n\nshowing 1–1 of 1\n\nupdated 19:47 UTC\n\nactive filters:tag:iac clear all\n\n[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)\n\nper page122436100", "description": "Posts tagged #iac from Luck Goes to Cloud.", "keywords": [ "2026", "mmxxvi", "environments", "pulumi", "first", "feed", "posts", "search", "catalog", "01all" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/en/posts/tag/iac" } }, { "id": "f06196020802eceb", "url": "https://blog.luckramos.com", "title": "Luck Goes to Cloud", "content": "Luck Goes to Cloud\nRedirecting to [/en](/en). [Português](/pt).", "keywords": [ "luck", "goes", "cloud", "redirecting", "português" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/" } }, { "id": "f61650a71ffafad4", "url": "https://blog.luckramos.com/pt/posts/category/DevOps", "title": "DevOps · /blog · Luck Goes to Cloud", "content": "#### ── SEARCH\n\n/\n\n#### ── CATALOG · MMXXVI\n\n**01Todos os posts00202DevOps00103Infraestrutura001\n\n#### ── BY YEAR\n\n2026\n\n#### ── TAGS\n\n#devops#environments#aws#cost#iac#pulumi#reliability#staging#terraform#testing\n\n#### ── SORT BY\n\n▸mais recentes▸mais antigos▸leituras mais longas▸random()\n\n$ luck --feed**Feed Atom em [/pt/rss.xml](/pt/rss.xml).\n\n/blog · the index · MMXXVI\n\n## DevOps · 1\n\nmostrando 1–1 de 1\n\natualizado 19:47 UTC\n\nfiltros ativos:cat:devops limpar tudo\n\n[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)\n\npor página122436100", "description": "Posts na categoria DevOps no Luck Goes to Cloud.", "keywords": [ "devops", "mais", "2026", "mmxxvi", "staging", "feed", "search", "catalog", "01todos", "posts00202devops00103infraestrutura001" ], "metadata": { "chunkIndex": 0, "totalChunks": 1, "sourcePath": "/pt/posts/category/DevOps" } } ], "metadata": { "totalEntries": 66, "generator": "aeo.js", "generatorUrl": "https://aeojs.org", "embedding": { "recommended": "text-embedding-ada-002", "dimensions": 1536 } } }