What Just Happened
You ran terraform apply (or plan, init) and got this:
Error: No configuration files
Apply requires configuration to be present. Applying without a configuration would mark everything for destruction, which is normally not what is wanted. If you still want to proceed, -destroy flag can be used to destroy resources without a configuration.
Terraform scanned your current directory and found zero .tf files. No files, no config, no party.
This tends to hit at the worst possible moment — mid-deploy, something urgent, and you've been running commands from the wrong directory the whole time. Or you cloned a repo and the structure wasn't what you expected. Either way, the fix is usually one cd away.
Debug Process
Step 1: Check where you actually are
pwd
ls -la
Scan the output for .tf files. See none? That's your culprit. Terraform requires at least one .tf file in the current directory — even an empty main.tf — to treat it as a valid configuration root.
Step 2: Find where your .tf files actually live
find . -name "*.tf" -type f 2>/dev/null
This searches the full directory tree from where you are. A few common scenarios:
- You're at the repo root, but configs live under
terraform/,infra/, orenvironments/prod/ - You cloned into a subfolder and never
cd'd into it - The directory only has
.tf.jsonfiles — Terraform supports JSON-format configs too, so they count - Someone renamed or deleted the
.tffiles without mentioning it
Step 3: Check if you're inside a module subdirectory by mistake
Say your repo looks like this:
infra/
├── main.tf
├── variables.tf
├── outputs.tf
└── modules/
└── networking/
├── main.tf
└── variables.tf
Running terraform apply from inside infra/modules/networking/ won't work as intended. Modules aren't standalone — they're meant to be called from a root module, not applied directly.
The Fix
Fix 1: Navigate to the correct directory
Nine times out of ten, this is all you need:
cd /path/to/your/terraform/root
terraform init
terraform plan
terraform apply
Before running anything, confirm you're in the right place:
ls *.tf
You should see something like:
main.tf outputs.tf providers.tf variables.tf
Fix 2: Use the -chdir flag (Terraform 0.14+)
Need to run Terraform from a fixed location — say, a CI script that always starts at the repo root? Use -chdir:
terraform -chdir=./terraform/environments/prod apply
Terraform switches into that directory before doing anything. It's the same as cd + command but in a single call. Much safer in scripts and pipelines where the working directory isn't guaranteed.
Fix 3: Create a minimal main.tf if you're bootstrapping
Starting fresh with no config yet? Create a minimal entry point:
touch main.tf
Or add a terraform block to pin the required version:
cat > main.tf <<'EOF'
terraform {
required_version = ">= 1.0"
}
EOF
Then run terraform init. An empty or near-empty main.tf satisfies the check. Terraform just needs something to work with.
Fix 4: If you actually intended to destroy resources
The error message hints at this case. To destroy everything in your state without a config file present, run:
terraform apply -destroy
Or with the classic command:
terraform destroy
Stop and think before hitting enter. If your state file references production resources, this marks all of them for deletion — without a config to constrain what gets destroyed.
Verify the Fix
Once you're in the right directory (or using -chdir), ask Terraform to validate the config:
terraform validate
Expected output:
Success! The configuration is valid.
Haven't run init yet in this directory? Do that first:
terraform init
terraform validate
terraform plan
A successful plan — even one showing zero changes — confirms Terraform found your config and can read it.
Common Repo Structures That Cause This
Teams organize Terraform repos in wildly different ways. These three patterns trip people up the most:
# Pattern 1: environment-based
infra/
└── environments/
├── dev/
│ └── main.tf ← run from here
├── staging/
│ └── main.tf
└── prod/
└── main.tf
# Pattern 2: component-based
terraform/
├── networking/
│ └── main.tf ← run from here
├── compute/
│ └── main.tf
└── databases/
└── main.tf
# Pattern 3: flat (small projects)
./
├── main.tf ← run from repo root
├── variables.tf
└── outputs.tf
Before touching any Terraform command in an unfamiliar repo, check the README or Makefile for the intended working directory. That 30-second check saves a lot of head-scratching.
Prevention
A few habits that stop this from recurring:
- Wrap commands in a Makefile or shell script that hardcodes the correct directory. Human error disappears entirely in CI/CD when the path is baked in.
- Add a
.terraform-versionfile to each root module directory. Tools liketfenvuse it for version pinning, and it doubles as a visual marker: "this is a Terraform root, apply from here." - Validate
.tfvarsYAML blocks before running — occasionally a variable file gets corrupted or has a syntax error that causes unexpected behavior. The YAML ↔ JSON Converter at toolcraft.app/en/tools/developer/yaml-json-converter runs in-browser with no uploads, so it's safe for internal config snippets. - Prefer
-chdirover barecdin CI pipelines. Acdthat fails silently will leave the pipeline running in the wrong place.-chdirfails loudly.
Lessons Learned
This error feels embarrassing — it's "just a wrong directory." But it catches experienced engineers too, especially in repos with 20+ Terraform modules spread across dev, staging, and prod environments. The worst version is the 2 AM incident: you're SSH'd into a bastion host, manually running Terraform to fix something on fire, and you're one directory level off.
The -chdir flag landed in 0.14 specifically because this was such a recurring pain. If a script might run from an unpredictable working directory, use it.
One last gotcha: if terraform plan runs fine but shows unexpected resources, you may be in the right type of directory but the wrong environment. Double-check you're targeting prod/ and not staging/ before applying.