Terraform turns VPS provisioning into a repeatable, version-controlled process that replaces manual clicks in a control panel. A plain text file holds the entire configuration, so you can review it, share it, and reapply it at any time. This terraform tutorial covers configuring the Contabo provider, writing a resource block, and running the first apply. The same steps apply to Contabo, a terraform digitalocean droplet, or any other cloud host with an available provider.
Setting Up the Terraform Provider for Contabo
Generating Contabo API Credentials
Contabo exposes its infrastructure through a REST API secured with OAuth2. The community-maintained Terraform provider wraps that API into standard resource blocks. Before writing any configuration, generate four credentials from the Contabo customer panel. These include a client ID, a client secret, an API user, and an API password. Create these under the API section of the account settings. They differ from the regular login credentials you use to access the panel itself. Generate these credentials first and set them aside, because the provider block fails to authenticate without all four values.
Declaring the Provider and Resource Block
Once the credentials are ready, declare the provider block in a file named main.tf. A typical setup looks like this:
terraform {
required_providers {
contabo = {
source = "contabo/contabo"
version = "~> 0.1"
}
}
}
provider "contabo" {
oauth2_client_id = var.client_id
oauth2_client_secret = var.client_secret
oauth2_user = var.api_user
oauth2_password = var.api_password
}
resource "contabo_instance" "vps_web" {
display_name = "terraform-web-01"
product_id = "V91"
region = "EU"
image_id = "afecbb85-e2fc-46f3-9d5b-573b7e6cf9b8"
ssh_keys = [contabo_secret.ssh_key.id]
}Store sensitive values like the client secret and API password as variables. Pass them in through a terraform.tfvars file or environment variables instead of hardcoding them directly in the configuration. This matters especially when the code goes into a shared repository. A common approach declares each credential in a variables.tf file with a sensitive flag set to true. It then keeps the actual values in a separate terraform.tfvars file, which a .gitignore entry excludes from version control. This setup keeps the configuration reusable across machines and collaborators without exposing real credentials in a shared repository.
Running Terraform Init and Apply
With the file saved, run terraform init to download the Contabo provider and set up the local working directory. This command creates a .terraform folder along with a lock file that pins the exact provider version. Run it again whenever the required_providers block changes; otherwise it only needs to run once per project. terraform plan then shows exactly what Terraform will create, which for a first run means a single VPS instance. Read through the plan output before applying anything. It lists every attribute Terraform intends to set and flags anything unexpected before real infrastructure changes.
Run terraform apply and confirm with yes to send the request to the Contabo API and provision the machine. Within a few minutes, the new VPS appears both in the Contabo customer panel and in Terraform’s state file. Other resources, such as firewalls or additional volumes, can reference it right away. The state file, named terraform.tfstate by default, lets Terraform track what already exists for the next plan or apply. Treat it carefully. Once a project grows beyond a single contributor, store this file in a remote backend. Avoid leaving it only on a local machine.
From Terraform on DigitalOcean to Terraform on Contabo
Anyone who already works with terraform digitalocean configurations recognizes most of this structure immediately. DigitalOcean’s provider uses a droplet resource with a size, region, and image, and it authenticates with a single API token. Contabo’s provider follows the same general shape, but a few practical differences appear once you start writing real configurations. Knowing them ahead of time saves a fair amount of trial and error.
Authentication Differences
The most obvious difference lies in authentication. DigitalOcean requires only one token. You generate it from the API section of the control panel and pass it directly into the provider block. Contabo’s OAuth2 flow needs four separate values, which adds setup time at the start. It doesn’t change how you write the rest of the configuration. Once the provider block authenticates correctly, both platforms behave the same way from Terraform’s perspective. You declare, plan, and apply resources through identical commands.
Naming Conventions and Regions
Naming conventions also differ in ways that trip up beginners moving between the two providers. DigitalOcean groups its machine sizes under human-readable slugs like s-1vcpu-1gb, which describe the hardware directly in the identifier. Contabo instead identifies its plans through product codes such as V91 or V92. These map to specific VPS tiers in its pricing documentation rather than describing the specs inline. Region handling works similarly. Contabo groups its data centers into broader zones like EU or US, while DigitalOcean offers city-level regions such as nyc1 or fra1.
Networking Resources
Networking resources widen the gap a little more. DigitalOcean maintains mature, well-documented resources for load balancers, VPCs, and floating IPs. Its own engineering team updates them alongside new platform features. Contabo’s provider, being community driven, currently covers instances, private networking, snapshots, and secrets. Contributors add new resources over time as the API surface grows. This means some advanced networking setups that work instantly on DigitalOcean may need a manual step in the Contabo panel. Others may need a workaround using the provider’s more limited resource set.
For a straightforward VPS with SSH access and basic firewall rules, the two providers feel very similar in daily use. Moving your mental model from one to the other takes very little adjustment. The core Terraform concepts, providers, resources, variables, outputs, and state, stay the same between them. What changes is mostly vocabulary and the level of detail each provider exposes.
Why Provision Your Contabo VPS with Terraform
Manually provisioning a VPS through a control panel works fine for a single server. It stops scaling once more than one environment needs to exist. Terraform vps configurations solve this by turning the entire setup, instance size, SSH keys, firewall rules, into a single text file. You can review, version, and reapply that file identically as many times as needed. A configuration written once can spin up a development server, a staging server, and a production server, all functionally identical. Changing a variable or two is all it takes.
Contabo Supplies the VPS, Not the Automation
It’s worth being clear about where the responsibility sits. Contabo provides the compute resource itself, the physical VPS running on its infrastructure. It doesn’t manage the Terraform configuration for you. The .tf files, the state file, and every decision about what gets provisioned remain entirely in your hands. This isn’t a managed automation service. It’s a self-directed workflow: Contabo supplies the hardware and the API, and Terraform simply talks to that API in a structured way. Contabo doesn’t monitor, back up, or maintain the configuration. Keeping the state file safe and the code under version control falls entirely on you.
Tracking Changes and Rebuilding Fast
That distinction matters because it also gives you full control over how changes get tracked. A configuration change that resizes a VPS or adds a firewall rule shows up clearly in terraform plan before anything happens. This lets you catch mistakes before they affect a running server. The same file can rebuild a near-identical staging server or recreate the exact production environment after a failure. That turns disaster recovery from a stressful improvisation into a matter of running terraform apply against a known-good configuration.
For anyone managing more than a handful of servers, that repeatability quickly outweighs the convenience of a few extra clicks in a control panel. The same goes for anyone who simply wants a record of what got deployed and why. Storing the configuration in a Git repository also gives every infrastructure change an associated commit message, author, and timestamp. That lets you audit server provisioning the same way you audit application code.
FAQ: Terraform on a VPS
Does Terraform work with Contabo?
Yes. A community-maintained provider, published under contabo/contabo in the Terraform registry, supports provisioning Contabo VPS instances. It also manages private networks, handles SSH secrets, and works with snapshots. It authenticates using OAuth2 credentials you generate in the Contabo customer panel. Once configured, it behaves like any other Terraform provider, so standard commands like plan and apply work exactly as expected. The community maintains the provider rather than Contabo itself, so check the registry page periodically for updates. New resources and bug fixes arrive on an ongoing basis rather than a fixed release schedule.
How is Terraform on Contabo different from Terraform on DigitalOcean?
The core workflow stays identical: define a provider block, declare a resource, run init and apply. The differences mostly show up in the details. Terraform digitalocean setups authenticate with a single API token. Contabo requires a client ID, client secret, API user, and API password, each generated separately from the customer panel. Contabo also identifies server sizes through product codes rather than descriptive slugs. Its provider also covers a narrower set of resources, since the community maintains it rather than the host itself. DigitalOcean’s longer track record gives it somewhat more extensive documentation and examples. None of this changes the fundamental structure of the configuration files or how you use Terraform day to day.
What’s the simplest Terraform tutorial for a new VPS?
The fastest path for a beginner uses a single-resource configuration. It needs one provider block with valid credentials and one resource block defining an instance with a size, region, and image. From there, run terraform init followed by terraform apply. Skipping variables, modules, and remote state at first keeps the learning curve manageable. It also makes it easier to see what each part of the configuration does. Once that first VPS runs and shows up in both the provider’s control panel and the Terraform state file, expanding it gets much easier. You can add resources like firewalls or private networks, then gradually introduce variables and modules as the setup grows more complex.