Build your first Terraform infrastructure in five minutes

What you will get

By the end of this guide, Scaleway's real Terraform provider will have created a server and an IP address on your machine, a second plan will report nothing to change, and feint down will have destroyed it all. No account will have been opened, no access key read, and nothing billed.

The whole thing takes about five minutes, half of it downloading the provider.

Why start here

A successful apply is the first signal, but it is not the one that counts. The real test of an infrastructure described in Terraform is that it converges: once created, a second plan must propose no change. This guide shows you both, in that order, because that is the reflex that serves you later on a real cloud.

Prerequisites

Terraform 1.7 or newer, or OpenTofu.
Git, to fetch the example.
feint, installed with one command below.

Nothing else: no account, no API key, no container engine. The emulator is a static binary holding its state in memory.

The lab, step by step

Install feint.
Fenêtre de terminal
```
brew install stephrobert/feint/feint
feint version
```
The output must print v0.13.0. If you prefer the signature-verified binary, or if you do not use Homebrew, the installation page covers the other channels.
Fetch the example, which lives in the project's repository.
Fenêtre de terminal
```
git clone https://github.com/stephrobert/feint
cd feint/examples/quickstart/scaleway
```
Only two files sit there: a main.tf short enough to read whole, and a feint.yaml describing the environment it needs.
Check the host before starting anything.
Fenêtre de terminal
```
feint doctor
```
Run from the stack's directory, doctor does more than check the port: it reads the Terraform files present and looks for the known signatures of a call that would leave for the real cloud.
```
ok    no variable measured to reroute outscale clients is set in this shell
ok    no known escape signature in the 1 Terraform file(s) here
```

Bring everything up in one command.

feint up

feint up reads the feint.yaml, checks what the host can deliver, starts the emulator, exports what the official client expects, runs Terraform in the directory, then waits for the conditions the file declares before handing back control.

feint.yaml: scaleway, runtime off, terraform in .
feint listening on 127.0.0.1:4599 (pid 3774695)
- terraform init in .
- Installing scaleway/scaleway v2.81.0...
- terraform apply in .
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.
- waiting: the emulator answers /instance/v1/zones/fr-par-1/servers
  ok: http:/instance/v1/zones/fr-par-1/servers
- waiting: the emulator holds a instance/server
  ok: resource:instance/server:1
- waiting: the emulator holds a instance/ip
  ok: resource:instance/ip:1

The end of the output recaps where to find what, which saves you remembering commands or digging them out of a shell history:

up: http://127.0.0.1:4599
  clients:  eval "$(feint env scaleway)"
  page:     http://127.0.0.1:4599/_feint/ui
  proved:   http:/instance/v1/zones/fr-par-1/servers, resource:instance/server:1, resource:instance/ip:1
  down:     feint down

Check convergence, which is the real test.
Fenêtre de terminal
```
terraform plan
```
```
No changes. Your infrastructure matches the configuration.
```
That line says something strong: the API read back the resources the way it accepted them. If a single value came back in another form, Terraform would propose a phantom change here, and you would have the same problem on the real cloud.
Look at what the emulator actually served.
Fenêtre de terminal
```
feint status
```
```
  provider    routes  driven by a client
  scaleway       193  12
  exoscale       104  0
  outscale       100  0
```
The right-hand column counts the routes a real client went through during your session: twelve here, the ones Terraform called to create then read back your two resources.
Destroy everything.
Fenêtre de terminal
```
feint down
```
```
Destroy complete! Resources: 2 destroyed.
feint: discarding 1 resource(s) (started without --state); `feint snapshot save <name>` before stopping would have kept them
```
The second line is not an error: the emulator reports that it is discarding a resource left in memory, and tells you how you would have kept it. An emulator that vanished silently with your data would be more annoying.

Break the lab on purpose

A testing guide must show a failure, otherwise it teaches nothing about diagnosis. Open main.tf and replace the server type with a value that does not exist, DEV1-XXL for instance, then run it again:

terraform apply

The provider refuses, and the emulator is what said so: the catalogue is a closed list, and a missing type is rejected the way Scaleway would. A nonexistent image identifier, on the other hand, would pass, and that is a deliberate limit the limits page explains.

That is already a useful lesson: this lab proves your configuration is well formed, not that every value it names exists somewhere.

What this lab proves

The real Terraform provider can talk to the emulator, in its pinned version 2.81.0.
Your configuration creates then reads back its resources consistently.
The state converges: the second plan is empty.
Destruction works, and the cleanup is complete.

What it does not prove

No machine started. This lab runs in control-plane mode: the API describes a server, nothing runs behind it. The real machines guide shows the other half.
The values are not the real cloud's: neither pricing, nor quotas, nor available capacity.
Nothing was authenticated. The exported credentials are well formed and fictitious, and the emulator verifies no signature.

Next steps

Learn Terraform without an account Use this same setup as a practice ground, as many times as you need.

Test a real stack Move from two resources to a realistic architecture, and tell the three levels of success apart.

Reproducible environment Understand the feint.yaml that just built all of it, field by field.