How to Version Control Your Infrastructure with Deployxa MCP
Infrastructure as code (IaC) is a standard practice for Kubernetes (via Terraform, Pulumi, Helm), but it is less common for PaaS platforms like Deployxa. This is a missed opportunity, because version-controlling your infrastructure (apps, environment variables, domains, scaling configuration) gives you the same benefits as version-controlling your code: auditability, reproducibility, and collaboration. With the Deployxa MCP server, you can version control your infrastructure by defining it in a configuration file (e.g., deployxa.json) and using the MCP server to apply changes. Here is how.
The direct answer is that version-controlling your Deployxa infrastructure means defining your apps, environment variables, domains, and scaling configuration in a configuration file (e.g., deployxa.json) that is committed to your repository. When you want to change your infrastructure, you modify the configuration file, commit the change, and run a script (or CI/CD pipeline) that calls the Deployxa MCP server to apply the changes. This gives you auditability (every infrastructure change is in your Git history), reproducibility (you can recreate your entire infrastructure from the configuration file), and collaboration (your team can review infrastructure changes via pull requests). For more on infrastructure patterns, see our article on why vibe coders should avoid Kubernetes.
Why Version Control Your Infrastructure
Three reasons explain why you should version control your infrastructure. First, auditability. Every infrastructure change (new app, changed environment variable, added domain) is recorded in your Git history, which means you can see who changed what and when. This is essential for compliance and for debugging (e.g., "when did the DATABASE_URL change?"). Second, reproducibility. If your Deployxa account is lost (e.g., you delete it accidentally), you can recreate your entire infrastructure from the configuration file, which means you are not locked into the platform. Third, collaboration. Infrastructure changes can be reviewed via pull requests, which means your team can discuss and approve changes before they are applied. This prevents accidental misconfigurations (e.g., someone sets DEBUG=true in production) and improves the quality of your infrastructure.
Without version control, infrastructure changes are made directly in the Deployxa dashboard, which means there is no record of who changed what, no way to review changes before they are applied, and no way to recreate the infrastructure if it is lost. This is fine for small apps with one developer, but it does not scale to teams or to apps with complex infrastructure.
What to Version Control
Here is what you should version control for each Deployxa app:
1. App configuration
The app's name, framework, runtime, build command, start command, and resource profile (CPU, memory). This is the basic configuration that defines the app.
2. Environment variables
All environment variables, with their values (for non-secrets) or references (for secrets). Secrets should not be committed to the repository; instead, reference them by name (e.g., "DATABASE_URL": "{{secret:DATABASE_URL}}") and store the actual values in a secrets manager (e.g., Doppler, AWS Secrets Manager) or in the Deployxa dashboard.
3. Custom domains
The custom domains configured for the app, including the SSL configuration. This lets you recreate the domain configuration if the app is lost.
4. Scaling configuration
The number of containers and the resource profile (CPU, memory) for each container. This lets you recreate the scaling configuration if the app is lost.
5. Health check configuration
The health check endpoint, interval, and timeout. This lets you recreate the health check configuration if the app is lost.
Step-by-Step: Version Controlling Your Deployxa Infrastructure
Here is how to version control your Deployxa infrastructure with a configuration file and the MCP server.
Step 1: Create the configuration file
Create a file named deployxa.json in your repository root:
{
"apps": [
{
"name": "my-app",
"framework": "nextjs",
"runtime": "node 20.x",
"buildCommand": "npm run build",
"startCommand": "npm start",
"resources": {
"cpu": 1.0,
"memory": 1024
},
"scaling": {
"minContainers": 1,
"maxContainers": 3
},
"healthCheck": {
"path": "/health",
"interval": 5,
"timeout": 10
},
"environmentVariables": {
"NEXT_PUBLIC_API_URL": "https://api.myapp.com",
"DATABASE_URL": "{{secret:DATABASE_URL}}",
"JWT_SECRET": "{{secret:JWT_SECRET}}",
"NODE_ENV": "production"
},
"domains": [
{
"domain": "myapp.com",
"ssl": true
}
]
},
{
"name": "my-api",
"framework": "fastapi",
"runtime": "python 3.11",
"buildCommand": "pip install -r requirements.txt",
"startCommand": "uvicorn main:app --host 0.0.0.0 --port $PORT",
"resources": {
"cpu": 1.0,
"memory": 1024
},
"scaling": {
"minContainers": 1,
"maxContainers": 5
},
"healthCheck": {
"path": "/health",
"interval": 5,
"timeout": 10
},
"environmentVariables": {
"DATABASE_URL": "{{secret:DATABASE_URL}}",
"REDIS_URL": "{{secret:REDIS_URL}}",
"STRIPE_SECRET_KEY": "{{secret:STRIPE_SECRET_KEY}}"
},
"domains": [
{
"domain": "api.myapp.com",
"ssl": true
}
]
}
]
}Step 2: Create the apply script
Create a script that reads deployxa.json and applies the configuration via the Deployxa MCP server:
# apply_infra.py
import json
import os
from deployxa_mcp import DeployxaMcpClient
client = DeployxaMcpClient(server_url="http://localhost:3000/mcp")
def resolve_secret(value):
"""Resolve a secret reference to its actual value."""
if value.startswith("{{secret:"):
secret_name = value[9:-2] # extract the secret name
return os.environ[secret_name] # get the value from the environment
return value
def apply_app_config(app_config):
"""Apply the configuration for a single app."""
# Check if the app exists
existing_apps = client.call_tool("deployxa_list_apps", {})
app = next((a for a in existing_apps["apps"] if a["name"] == app_config["name"]), None)
if app is None:
# Create the app
result = client.call_tool("deployxa_create_app", {
"name": app_config["name"],
"framework": app_config["framework"],
"runtime": app_config["runtime"],
"build_command": app_config["buildCommand"],
"start_command": app_config["startCommand"],
"cpu": app_config["resources"]["cpu"],
"memory": app_config["resources"]["memory"],
})
app_id = result["app_id"]
else:
app_id = app["id"]
# Set environment variables
for key, value in app_config["environmentVariables"].items():
resolved_value = resolve_secret(value)
client.call_tool("deployxa_set_env_var", {
"app_id": app_id,
"key": key,
"value": resolved_value,
})
# Configure domains
for domain in app_config["domains"]:
client.call_tool("deployxa_add_domain", {
"app_id": app_id,
"domain": domain["domain"],
"ssl": domain["ssl"],
})
print(f"Applied configuration for {app_config['name']}")
def main():
with open("deployxa.json") as f:
config = json.load(f)
for app_config in config["apps"]:
apply_app_config(app_config)
print("Infrastructure applied successfully")
if __name__ == "__main__":
main()Step 3: Commit the configuration file
git add deployxa.json apply_infra.py
git commit -m "add infrastructure as code configuration"
git pushStep 4: Apply the configuration
Set the secret values as environment variables (from your secrets manager), then run the apply script:
export DATABASE_URL="postgresql://..."
export JWT_SECRET="..."
export REDIS_URL="redis://..."
export STRIPE_SECRET_KEY="sk_live_..."
python apply_infra.pyThe script reads deployxa.json, resolves the secret references, and applies the configuration via the Deployxa MCP server.
Step 5: Integrate with CI/CD
Add the apply script to your CI/CD pipeline, so infrastructure changes are applied automatically when you merge a pull request:
# .github/workflows/apply-infra.yml
name: Apply Infrastructure
on:
push:
branches: [main]
paths:
- 'deployxa.json'
jobs:
apply:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v4
with:
python-version: '3.11'
- run: pip install deployxa-mcp
- run: python apply_infra.py
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
JWT_SECRET: ${{ secrets.JWT_SECRET }}
REDIS_URL: ${{ secrets.REDIS_URL }}
STRIPE_SECRET_KEY: ${{ secrets.STRIPE_SECRET_KEY }}Now, whenever you modify deployxa.json and merge to main, GitHub Actions automatically applies the changes to your Deployxa account.
Common Pitfalls and Troubleshooting
The first pitfall is committing secrets to the repository. Never commit actual secret values to deployxa.json; always use secret references (e.g., {{secret:DATABASE_URL}}) and store the actual values in a secrets manager or in the Deployxa dashboard. The second pitfall is configuration drift. If someone makes changes in the Deployxa dashboard (instead of in deployxa.json), the configuration file and the actual infrastructure diverge. The fix is to periodically run a diff script that compares deployxa.json to the actual infrastructure and reports any differences. The third pitfall is destructive changes. If you remove an app from deployxa.json and run the apply script, the script might delete the app (and its data). The fix is to require explicit confirmation for destructive changes, or to never delete apps automatically (just create and update). The fourth pitfall is secret rotation. When you rotate a secret (e.g., because it was compromised), you need to update it in your secrets manager and in the Deployxa dashboard. The fix is to integrate the apply script with your secrets manager, so secret rotations are applied automatically. The fifth pitfall is multi-environment configuration. You might have different infrastructure for staging and production (e.g., different database URLs, different domain names). The fix is to use environment-specific configuration files (e.g., deployxa.staging.json and deployxa.production.json) and to apply the correct one based on the CI/CD environment.
Advanced IaC Patterns
Beyond the basics, infrastructure as code with Deployxa can be extended with several advanced patterns. The first is drift detection. A drift detection script periodically compares deployxa.json to the actual infrastructure and alerts on differences, which catches manual changes that were not committed to the repository. The second is infrastructure testing. You can write tests that verify your infrastructure is configured correctly (e.g., "the production app should have SSL enabled", "the staging app should not have a custom domain"). The third is infrastructure cost estimation. The configuration file can include cost estimates for each app, which helps you track and optimize your infrastructure spending. The fourth is multi-region deployment. For apps that need to run in multiple regions (e.g., via Fly.io), the configuration file can specify the regions, and the apply script can deploy to each. The fifth is integration with Terraform. For teams that already use Terraform, the Deployxa MCP server can be exposed as a Terraform provider, which lets you manage Deployxa infrastructure alongside your other Terraform-managed infrastructure. For more on advanced patterns, see our articles on building a self-healing CI/CD pipeline and the agentic deployment checklist.
Conclusion: Treat Infrastructure Like Code
Version-controlling your infrastructure gives you auditability, reproducibility, and collaboration, which are essential for teams and for apps with complex infrastructure. With a configuration file (deployxa.json) and the Deployxa MCP server, you can treat your infrastructure like code, which means you can review changes, track history, and recreate your infrastructure from scratch. Stop making infrastructure changes in the dashboard and start version-controlling them.
Ready to version control your infrastructure? Install the Deployxa MCP server with npm i -g @deployxa/mcp-server, run deployxa-mcp login, and create your deployxa.json file. For more on agentic workflows, see our articles on the agentic incident response pipeline and building an AI agent that monitors your app 24/7. Learn about building a Slack bot that deploys apps and how to use the Deployxa MCP server with Claude Code CLI in our companion articles. Explore our free developer tools to speed up your workflow.