Infrastructure described in code, ready to rebuild
We describe your AWS, Google Cloud or Azure environments in code, from network to permissions, so every change is reviewed and any environment can be rebuilt.
Who it's for
For companies whose infrastructure was clicked together in the provider's console, and nobody knows how to rebuild it.
What it solves
- Staging and production were set up differently, so the bug only shows up in production.
- Only one person knows how the infrastructure was configured, and they are leaving.
- Passwords and access keys get passed around in spreadsheets, emails and chat messages.
- Nobody can say who changed a network rule, or when.
What we do
- Infrastructure as code
- Every cloud resource described in versioned files; each change is reviewed before it is applied.
- Matching environments
- Development, staging and production come from the same description, changing only what has to differ.
- Containers
- Applications packaged in containers; Kubernetes only when the size of the system justifies it.
- Secrets vault
- Passwords and keys kept out of the code, with role-based access and a record of who read what.
- Network and permissions
- A private network, ports closed by default and every person or service with the least access it needs.
- Region and accounts
- A region in Brazil or abroad and separate accounts per environment, decided with you.
What you get
- A repository with the infrastructure described in code, reviewed and documented
- Staging and production environments created from that repository
- A configured secrets vault, with a record of who accesses what
- A diagram of the network and environments
- A tested runbook for rebuilding an environment from scratch
How we do it
Survey
What exists in the account today, who has access and what was done by hand.
Design
Environments, network, region and permissions agreed before anything changes.
Into code
Existing resources are brought into code without rebuilding what already works.
Rehearsal
A whole environment rebuilt from scratch, to prove the description is complete.
Handover
Documentation and a session with your team on running and changing the infrastructure.
Technology examples
- Terraform
- OpenTofu
- Pulumi
- Docker
- Kubernetes
- AWS
- Google Cloud
- Azure
Related services
FAQ
Do we need to switch cloud provider?
No. If you are already on AWS, Google Cloud or Azure, we start from there. Switching provider is a separate decision, worth it only with a clear reason in cost or operations.
Can this be done while the system is live?
Yes. Existing resources move into code step by step, without rebuilding what already works. When a change needs downtime, it is agreed in advance, with a time slot and a way back.
Why not keep using the provider's console?
The console is fine for looking. A change made there skips review and is hard to repeat in another environment. In code, it goes through the same release pipeline as the rest of the software.
Whose name are the cloud accounts in?
Your company's, since it owns them. We receive only the access the work requires, and you can withdraw it when the work ends.
Write to Balkan
Talk to us about your project