A brand-new cloud account is the easiest place to adopt infrastructure as code, because there is nothing to import and no one to argue with. Every resource created by hand in the first week becomes a resource someone has to reverse-engineer later. This guide covers the decisions that matter on day one: where state lives, how secrets stay out of the repository, how environments are split, and how the account’s API credentials are scoped. The examples reference Scaleway and Civo, both of which expose a REST API, a CLI and Terraform support.
Decide where state lives before the first apply
Tools such as Terraform and OpenTofu keep a state file that maps your code to real resources. Local state on a laptop is the default and the most common cause of disasters: a lost laptop or a second engineer means drift. Put state in remote storage from the first run.
- Use the provider’s S3-compatible object storage as the backend. Scaleway Object Storage and Civo Object Storage both support this.
- Enable versioning on the bucket so a corrupted state can be rolled back.
- Restrict access to the bucket to the automation identity and a small set of humans.
- Use state locking if the backend supports it, so two applies cannot collide.
The bucket itself is the one resource you may create by hand. Document that fact in the repository README.
Keep secrets out of code entirely
API tokens, database passwords and TLS keys never belong in the repository, not even encrypted “for now.” Inject them at apply time from environment variables or a secrets manager, and mark outputs that contain sensitive values so they are not printed in logs. Rotate any token that was ever committed, even briefly; the key rotation guide describes the procedure.
For a new account, create a dedicated automation identity with its own API key rather than using the account owner’s credentials. Scaleway’s Identity and Access Management lets you scope keys to a Project; Civo issues API keys per account that you should treat as production secrets from the moment they exist.
Separate environments from the start
Even a solo developer benefits from a production and a non-production environment. The cleanest split uses whatever boundary the provider offers: Scaleway Projects, or separate Civo accounts or clusters. Structure the code so an environment is a set of variables, not a copy of the directory.
| Layer | Contents | Changes how often |
|---|---|---|
| Foundation | Networks, security groups, state bucket, IAM | Rarely |
| Platform | Kubernetes cluster, databases, load balancers | Monthly |
| Application | Instances, node pools, DNS records | Weekly or daily |
Keeping these in separate state files means a routine application change cannot accidentally destroy the network.
The first pull request
Make the first real change through the same path every later change will use: a branch, a plan output attached to the pull request, a review, and an apply from CI rather than a laptop. On Civo, that first change is often a small Kubernetes cluster, since the platform is Kubernetes-first and the control plane carries no charge. On Scaleway, it is typically a Development Instance in a Private Network. Both are cheap enough to create and destroy repeatedly while the pipeline is tuned.
The Civo Cloud $250 Credit Account and the Scaleway ID Verified+Card Account listed on the marketplace are both suitable starting points for this kind of setup, provided the balance, verification status and terms are confirmed before use.
Guardrails worth adding early
- A budget alert defined in code alongside the resources it protects
- Tags or labels for environment and owner on every resource
- Deletion protection on the database and the state bucket
- A scheduled plan in CI that flags drift when someone changes something by hand
What not to automate yet
Do not write modules for things you have created once. Do not abstract over multiple providers before you have a second provider. Do not build a self-service platform for a team of two. Infrastructure as code pays off through repeatability and review, not through cleverness. Start with plain resources, and refactor into modules when the same block appears a third time.
A new account with remote state, scoped credentials, two environments and CI-driven applies is already ahead of most production estates. The cost control guide and the monitoring first steps cover the operational pieces that sit alongside the code.
