Undeploy Applications¶
How to remove deployments and clean up environments on Airbase
This guide shows you how to safely destroy environments and clean up resources when you no longer need them.
Overview¶
What you'll learn: - Destroy individual environments - Understand what gets deleted - Follow safe cleanup procedures - Recover from accidental deletions
Time: 5 minutes
Understanding Undeployment¶
What Happens When You Undeploy¶
When you destroy an environment, Airbase removes:
✅ Kubernetes resources: - Deployment - Pods - Service - Ingress (URL routing)
✅ Environment configuration: - Environment variables - Resource allocations
❌ What is NOT deleted: - Container images in registry - Git repository - Local files - Other environments
Important: Undeployment only affects the specified environment. Other environments remain running.
Basic Undeployment¶
Destroy a Named Environment¶
Command:
What this does: 1. Removes staging environment 2. Deletes all Kubernetes resources 3. Frees up allocated resources 4. URL becomes inaccessible
Example output:
Destroying staging environment...
✓ Deployment removed
✓ Service removed
✓ Ingress removed
✓ Environment destroyed successfully
Time: ~30 seconds
Destroy Production Environment¶
Command:
⚠️ Warning: This destroys your production environment!
Safety prompt:
If you omit --yes, Airbase will ask for confirmation:
Best practice: Always use the interactive prompt for production.
Safety Guidelines¶
Before You Undeploy¶
Checklist:
- Verify you're destroying the correct environment
- Check no users are currently accessing the application
- Ensure you have backups (if needed)
- Confirm with team members (for shared environments)
- Document reason for deletion
Verification Steps¶
Step 1: Check which environment you're targeting
Step 2: List all environments
# See all running environments for your project
# (Currently requires Airbase API access or platform UI)
Step 3: Verify URL before destroying
# Visit the environment URL to confirm it's the right one
open https://staging--myproject.app.tc1.airbase.sg
Production Protection¶
Never: - ❌ Destroy production without team approval - ❌ Use --yes flag for production (use interactive prompt) - ❌ Destroy production while users are active - ❌ Destroy without backup plan
Always: - ✅ Get explicit approval for production changes - ✅ Schedule downtime if necessary - ✅ Notify stakeholders - ✅ Have rollback plan ready
Common Scenarios¶
Scenario 1: Clean Up Feature Branch Environment¶
Situation: Feature branch merged, environment no longer needed
Steps:
# 1. Verify feature is merged
git branch --merged main | grep feature-auth
# Output: feature-auth
# 2. Destroy the environment
airbase container destroy --yes feature-auth
# 3. Delete local branch
git branch -d feature-auth
# 4. Delete remote branch
git push origin --delete feature-auth
Result: Clean git history and no unused Airbase resources.
Scenario 2: Replace Staging with New Deployment¶
Situation: Want to redeploy staging from scratch
Steps:
# 1. Destroy existing staging
airbase container destroy --yes staging
# 2. Rebuild and redeploy
airbase container build
airbase container deploy --yes staging
Use case: Starting fresh after major configuration changes.
Scenario 3: Temporary Environment Cleanup¶
Situation: Created temporary environment for demo, now finished
Steps:
# Destroy demo environment
airbase container destroy --yes demo-client-presentation
# Remove local .env file if created
rm .env.demo-client-presentation
Benefit: Keeps environment list clean and reduces costs.
Scenario 4: Project Decommissioning¶
Situation: Entire project being shut down
Steps:
# 1. Destroy all environments (one by one)
airbase container destroy --yes development
airbase container destroy --yes staging
airbase container destroy --yes # production
# 2. Archive git repository
# 3. Document decommissioning in team wiki
# 4. Notify stakeholders
What Happens to Data¶
Stateless Applications¶
If your app doesn't store data: - No data loss concerns - Can be redeployed anytime - Clean slate on redeploy
Example: APIs that only query external databases
Stateful Applications¶
If your app stores data (volumes, databases):
⚠️ Important: Airbase does not currently support persistent volumes
Recommendations: 1. Use external databases (separate from Airbase) 2. Store data in external storage (S3, etc.) 3. Back up data before destroying environment
Example architecture:
On undeploy: Only the Airbase container is destroyed. External resources remain.
Troubleshooting¶
Issue: Cannot destroy environment¶
Symptom: Destroy command fails or hangs
Possible causes: 1. Environment doesn't exist 2. Network connectivity issues 3. Permission issues
Solution:
Check environment exists:
# Try to deploy first to see if it exists
airbase container deploy --yes staging
# If it says "not found", environment doesn't exist
Check connectivity:
Issue: Environment still accessible after destroy¶
Symptom: URL still works after running destroy command
Cause: DNS caching or destroy not completed
Solution:
Wait 1-2 minutes for changes to propagate:
# Try accessing URL again
curl https://staging--myproject.app.tc1.airbase.sg
# Should return connection refused or 404
Clear DNS cache (macOS):
Issue: Destroyed wrong environment¶
Symptom: Accidentally destroyed production instead of staging
Recovery steps:
-
Don't panic - Container images still exist
-
Redeploy immediately:
-
Check application:
-
Verify environment variables:
-
Test functionality:
Recovery time: 1-2 minutes (time to redeploy)
Data loss: None (if using external database)
Environment Lifecycle Management¶
Regular Cleanup Schedule¶
Recommended: - Weekly: Review feature branch environments - Monthly: Audit all non-production environments - Quarterly: Verify production is current
Cleanup criteria:
Destroy if:
- Feature branch merged > 7 days ago
- No deployments in > 30 days
- Owner no longer on team
- Project deprecated
Naming Convention for Easy Cleanup¶
Good naming:
feature-auth-2024-01 # Includes date
demo-client-a-2024-03-15 # Includes date and purpose
poc-new-framework # Clear purpose
Benefit: Easy to identify old environments
Cleanup script example:
#!/bin/bash
# cleanup-old-environments.sh
# List of environments to potentially clean up
ENVIRONMENTS=(
"feature-old-ui"
"demo-jan-2024"
"poc-experiment"
)
for env in "${ENVIRONMENTS[@]}"; do
echo "Destroy $env? (y/N)"
read -r response
if [[ "$response" =~ ^[Yy]$ ]]; then
airbase container destroy --yes "$env"
fi
done
Cost Optimization¶
When to Destroy Environments¶
Destroy immediately after: - Feature merged to main - Demo completed - POC concluded - Testing finished
Keep running: - Active development - Staging (for pre-production testing) - Production (obviously!)
Instance Type Considerations¶
Instead of destroying, consider downsizing:
Before destroying, ask: "Could I just use a smaller instance?"
// airbase.json - Downsize instead of destroy
{
"instanceType": "nano" // Smallest, cheapest option
}
Redeploy with smaller instance:
Use case: Keeping staging alive but reducing costs.
Redeployment After Destruction¶
Redeploy Same Code¶
Scenario: Destroyed by accident, want same version back
Important: This works because container images persist in registry.
Redeploy Different Code¶
Scenario: Destroyed old environment, want to deploy new code
# 1. Checkout desired branch
git checkout main
# 2. Rebuild
airbase container build
# 3. Deploy
airbase container deploy --yes staging
Checklist¶
Before destroying an environment:
- Verified environment name is correct
- Confirmed no users are actively using it
- Checked it's not production (or have approval)
- Backed up any necessary data
- Documented reason for deletion
- Notified team members (if shared environment)
- Removed associated git branches (if applicable)
- Cleaned up local
.env.<environment>files
After destroying:
- Verified URL is inaccessible
- Removed from team documentation
- Updated project tracking (if applicable)
FAQ¶
Can I undo an undeploy?¶
No, undeployment is permanent. However, you can redeploy the same code:
This creates a new environment with the same name.
What happens to my container images?¶
Container images remain in the registry even after destroying environments. You can redeploy them anytime.
Can I destroy multiple environments at once?¶
No, you must destroy each environment individually:
airbase container destroy --yes env1
airbase container destroy --yes env2
airbase container destroy --yes env3
Does destroying an environment affect my git repository?¶
No, undeployment only affects Airbase resources. Your git repository is unchanged.
How quickly does an environment get destroyed?¶
30 seconds to 1 minute typically. The URL becomes inaccessible immediately, but full cleanup may take slightly longer.
Can I destroy an environment and redeploy with the same name?¶
Yes! Environment names can be reused:
# Destroy
airbase container destroy --yes feature-x
# Later, redeploy
airbase container deploy --yes feature-x
What if I need to recover data from a destroyed environment?¶
If you're using external databases (recommended), data is safe.
If data was stored in the container (not recommended), data is lost. Always use external storage for important data.
See Also¶
- How-To: Manage Environments - Creating and managing environments
- How-To: Build and Deploy - Deployment workflow
- Explanation: Environments Concept - Understanding environments
- Reference: CLI Commands - Complete CLI reference