Powerful capabilities for managing complex infrastructure including resource graphs, project cloning, Terraform outputs, and file operations.
Visualize dependencies between your Terraform resources to understand relationships and troubleshoot issues.
A resource graph shows how your infrastructure resources depend on each other. For example, a database might depend on a VPC, which depends on an internet gateway. ops0 automatically builds this graph from your Terraform code.
Open the IaC project you want to visualize.
Find the Resource Graph button in the project toolbar.
View resources as nodes and dependencies as arrows connecting them.
Resource graphs are built from your Terraform state file. Run a deployment first if you don't see the graph option.
Duplicate entire IaC projects to create dev/staging/prod environments or experiment safely.
| Component | Status | Note |
|---|---|---|
| Terraform Files | ✅ | Files, directory structure |
| Project Settings | ✅ | Cloud provider, region |
| Variable Definitions | ✅ | terraform.tfvars content |
| Terraform State | ❌ | Clones start fresh |
| Deployment History | ❌ | History starts empty |
| GitHub Sync | ❌ | Must be re-configured |
Click the ⋮ menu in the project list or project header.
Choose the duplicate option from the dropdown.
my-app-staging)Click Duplicate to create the new project.
After cloning, you'll typically want to:
Change prefixes or suffixes to avoid conflicts.
# Original
resource "aws_s3_bucket" "prod_data" {
bucket = "my-app-prod-data"
}
# Cloned (update this)
resource "aws_s3_bucket" "staging_data" {
bucket = "my-app-staging-data"
}
Update environment-specific values.
# Use different instance sizes for staging
variable "instance_type" {
default = "t3.medium" # Was t3.xlarge in prod
}
Deploy to a different AWS region or GCP zone.
Link to a different cloud account if needed.
Always rename resources in cloned projects to prevent name collisions with the original infrastructure.
prod-, staging-, dev-View and refresh Terraform output values without redeploying your infrastructure.
Outputs expose values from your infrastructure for use in other systems or for reference. Common examples:
output "load_balancer_url" {
description = "Public URL of the load balancer"
value = aws_lb.main.dns_name
}
output "database_endpoint" {
description = "RDS database endpoint"
value = aws_db_instance.main.endpoint
sensitive = true # Marks output as sensitive
}
output "vpc_id" {
description = "VPC ID for cross-stack references"
value = aws_vpc.main.id
}
Navigate to the IaC project with deployed infrastructure.
Find the button in the project toolbar.
The Outputs tab shows all defined outputs with their current values.
Click the ⟳ refresh button to fetch the latest values from your state.
Copy to Clipboard
Sensitive Output Protection
sensitive = true are masked: ••••••••••••••••Type Display
Search and Filter
Terraform outputs reflect the current state of your infrastructure. Refresh outputs when:
Refreshing outputs runs terraform output against your state file. It doesn't modify infrastructure or trigger a new deployment.
Rename Terraform files in your project to reorganize your infrastructure code.
In the file explorer, right-click the file you want to rename.
Choose the rename option from the context menu.
Type the new file path/name in the modal.
Click Rename to apply the change.
Use forward slashes for directory paths:
modules/networking/vpc.tf
environments/prod/main.tf
resources/database.tf
Renaming files doesn't automatically update module source paths or references in other files. Update these manually after renaming.
Check after renaming:
terraform blocksterraform validate to catch broken references✓ database.tf, networking.tf, storage.tf
✗ main.tf, resources.tf, stuff.tf
Every change to a Terraform file creates a new version, allowing you to track the evolution of your infrastructure code.
ops0 automatically versions files when you:
Each file version includes:
Version history is maintained in the database and accessible through deployment history:
Configure Terraform backend to store state remotely in S3, enabling team collaboration and state locking for safe concurrent operations.
Local State Limitations:
Remote Backend Benefits:
ops0 supports multiple backend configurations:
| Backend Type | Storage | Locking | Use Case |
|---|---|---|---|
| Local | ops0 database | ✅ Database locks | Single user, simple projects |
| S3 | AWS S3 bucket | ✅ DynamoDB table | Team collaboration, production workloads |
| Custom Remote | Your S3 bucket | ✅ Your DynamoDB table | Enterprise, compliance requirements |
Configure remote state storage using AWS S3 and DynamoDB for locking.
Ensure your project has an AWS integration configured with appropriate permissions.
The AWS integration needs these permissions:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::your-terraform-state-bucket",
"arn:aws:s3:::your-terraform-state-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:DeleteItem"
],
"Resource": "arn:aws:dynamodb:*:*:table/terraform-state-lock"
}
]
}
Create an S3 bucket for state storage (or use ops0 auto-creation).
Create a DynamoDB table for state locking with partition key LockID (string).
Open your IaC project and click Settings in the toolbar.
Click the Backend Configuration tab.
Select S3 Remote Backend.
Enter backend configuration:
your-company-terraform-stateprojects/${project_name}/terraform.tfstateus-east-1terraform-state-lockClick Test Backend to verify ops0 can access S3 and DynamoDB.
Click Save to apply backend settings.
ops0 automatically adds this to your Terraform configuration:
terraform {
backend "s3" {
bucket = "your-company-terraform-state"
key = "projects/my-project/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-state-lock"
encrypt = true
}
}
If you had local state, it's automatically migrated to S3 on next deployment.
DynamoDB table tracks state locks to prevent concurrent modifications.
State locking prevents multiple users or deployments from modifying infrastructure simultaneously, which could corrupt the state file.
When you start a deployment, ops0 attempts to acquire a lock.
A lock entry is created in DynamoDB table with:
Only this deployment can modify infrastructure while lock is held.
After deployment completes (or fails), lock is automatically released.
State Lock Status
─────────────────────────────────────
Status: Locked
Locked by: Deployment #47
User: sarah@company.com
Started: 2024-01-15 10:30:00 UTC
Duration: 2m 15s
Operation: terraform apply
Scenario: You try to deploy while another deployment is running.
ops0 Response:
⚠️ State Lock Conflict
The Terraform state is currently locked by another deployment.
Locked by: Deployment #46
User: mike@company.com
Started: 3 minutes ago
Operation: terraform apply
Options:
- Wait for deployment #46 to complete
- Cancel deployment #46 (requires permission)
- Force unlock (dangerous - only if deployment is truly stuck)
Only force unlock if you're certain the locking deployment has crashed or been abandoned. Force unlocking during an active deployment can corrupt your state file.
View the current Terraform state without downloading or exposing sensitive data.
Navigate to your IaC project.
Find the View State button in project toolbar.
The state viewer shows:
Resource List
Resource Details
State Metadata
Migrate between local and remote backends or between different remote configurations.
Set up S3 backend configuration as described above.
On next deployment, ops0 prompts:
Backend Migration Detected
─────────────────────────────────────
Current Backend: Local (ops0 database)
New Backend: S3 (your-company-terraform-state)
Terraform will copy your state file from local to S3.
This is safe and reversible. Your local state will be
backed up before migration.
[Proceed with Migration] [Cancel]
During deployment initialization:
Check S3 bucket to confirm state file exists at configured key.
Change S3 bucket or key path:
Change S3 bucket name or key in project settings.
Terraform will:
Optionally delete state file from old S3 location (manual step).
Teams with existing IaC repositories (Terraform, OpenTofu, Oxid, etc.) can connect them directly to ops0 and start working immediately.
Create a new IaC project in ops0 and select your engine (Terraform, OpenTofu, or Oxid).
Link your existing GitHub or GitLab repository via the integrations page. ops0 syncs your .tf files automatically with two-way sync.
Set up a state backend (S3, GCS, Azure Blob, or Oxid). If your state already lives in a remote backend, point ops0 to the same location. Terraform handles state initialization automatically.
Run a plan to verify everything is in sync. Your existing code, modules, providers, and state work without modification.
Alternatively, teams starting fresh can use Discovery to scan existing cloud resources and generate IaC code automatically.
Download state file for local inspection or backup:
Navigate to View State in project toolbar.
Click the Download State button.
State downloads as terraform.tfstate JSON file.
Use Cases:
ops0 automatically creates state backups:
| Event | Backup Created |
|---|---|
| Before Apply | State backed up before deployment |
| After Apply | New state version stored |
| Backend Migration | Both old and new states saved |
| Force Unlock | State backed up before unlocking |
View backup history in Project → State History.
Open Project → Settings → State History.
Choose the backup version to restore.
Compare current state vs backup state.
Click Restore This Version.
Run terraform plan to see if infrastructure matches restored state.
Restoring an old state file can cause Terraform to think resources were deleted if they were created after that backup. Always review the plan output carefully after restoring state.
Symptoms: Deployment fails with "access denied" or "bucket not found".
Checks:
Solution: Update IAM permissions or bucket policy to grant access.
Symptoms: "Error acquiring state lock" or "lock table not found".
Checks:
LockID (case-sensitive)Solution: Create table or update permissions.
Symptoms: Deployment failed but lock never released.
Cause: Process crashed before releasing lock.
Solution:
Symptoms: Terraform plan fails with "state file corrupted" or JSON parse errors.
Recovery:
terraform plan to verifyFor projects with 20+ files, use this structure:
main.tf # Provider and backend configuration
variables.tf # Variable definitions
outputs.tf # Output definitions
modules/
networking/
vpc.tf
subnets.tf
security_groups.tf
compute/
instances.tf
autoscaling.tf
data/
databases.tf
storage.tf
Group related outputs together:
# Application outputs
output "app_url" { ... }
output "app_health_endpoint" { ... }
# Database outputs
output "db_endpoint" { ... }
output "db_port" { ... }
# Networking outputs
output "vpc_id" { ... }
output "subnet_ids" { ... }
Possible causes:
Solution: Run a successful deployment to create the state file.
Common issues:
edit or admin role on the projectCheck:
Fix:
source paths that referenced the old filenameterraform validate to identify broken references