🏰 Castle Black - Daydream Deployment Watch

Help

Castle Black is your deployment dashboard - it gives you a unified view of all your applications across dev, staging, and production environments.

What you can do:

• Monitor deployments: See version differences across environments at a glance
• Check health status: View ArgoCD health and sync status across all environments
• Promote to production: One-click promotions from staging to production
• Track recent changes: Spot recently updated deployments with the ⏰ indicator
• Quick navigation: Jump directly to ArgoCD, GitHub, or other Castle Black environments
• Filter and search: Find specific apps or namespaces quickly

Why use it?

• Save time by having all deployment info in one place
• Reduce deployment errors with visual version comparisons
• Streamline your promotion workflow
• Stay informed about deployment health across environments

Castle Black is owned and maintained by the SRE team.

Need help or want to report an issue?

• Contact us in the #platform-eng Slack channel

Want to contribute?

• Discuss ideas and suggestions in #platform-eng
• Pull requests are welcome at: https://github.com/dahlialabs/py-platform

Mostly no. Castle Black provides the same core functionality across all environments with cross-environment visibility.

What's the same everywhere:

• View health/sync status across dev, staging, and production
• Compare versions between environments
• Promote to production from any environment
• All core features and functionality

What's environment-specific:

• Configuration warnings: Some warnings (like "Autosync not enabled") only work for the current environment's ArgoCD
• New features: Released to dev first, so you get early access to improvements there

Recommendation: Use the environment you want to monitor for the most complete warning coverage, or use production for the most stable experience.

Environment URLs:

• Dev: https://castle-black.dev.dahlialabs.dev (newest features)
• Staging: https://castle-black.stag.dahlialabs.dev
• Production: https://castle-black.dahlialabs.dev (most stable)

The 📦 icon in the Dev column indicates that there's a pending release-please PR affecting this app. The system automatically determines which apps are affected by analyzing the PR title:

📦 Icon appears for:

• Repo-wide releases: chore: release 1.2.3 → affects ALL apps from that repository
• App-specific releases: chore(authentik): release 2025.8.4 → affects only the 'authentik' app
• Generic scopes: chore(main): release 1.0.0 → affects ALL apps (main/master/release/deps)

📦 Icon does NOT appear when:

• PR scope targets a different app: chore(other-app): release 1.0.0
• Case mismatch: chore(API): release 1.0.0 won't match app 'api'
• App name variations don't match exactly

💡 Tips:

• Click the 📦 icon to go directly to the release PR on GitHub
• If the icon seems incorrect, check the PR title format and app name matching
• The detection is case-sensitive and matches exact app names
• Note: Icons are based on PR title analysis only - there may be false positives since we don't know what the PR will actually deploy

Available filters:

• Search: Use the search box to filter by application name, namespace, or version numbers
• Namespace: Use the dropdown to filter by specific namespaces
• Version Mismatches: Toggle to show only applications with version differences between environments
• Recent Updates: Toggle to show only recently updated applications

URL Parameters for bookmarking:

• ?ns=namespace - Filter by namespace
• ?search=term - Search filter
• ?mismatches=1 - Show only version mismatches

• ArgoCD: Click the ArgoCD logo next to any environment to view the deployment in ArgoCD
• GitHub Source: Click the GitHub logo next to app names to view the source repository
• Config Version: Click version badges to view the specific config version in argocd-app-config

Why do errors link to source repos instead of staging configs?

Even when errors say "missing from staging," the fix is always in the source repo. CI/CD copies files from source repo to staging, so you need to add/fix configs in the source repo at the specific tag being promoted.

How does tag inference work for monorepos?

If no tagPrefix specified, Castle Black tries {app-name}@{version} first, then falls back to plain {version}. With tagPrefix: "castle-black@", it uses exactly castle-black@v1.0.0 with no fallbacks.

What's the difference between promotion_metadata.yaml and metadata.json?

promotion_metadata.yaml = project-level config for finding deployment files (sourceRepo, configPath, tagPrefix). metadata.json = environment-specific ArgoCD app config (targetRevision, name, chart).

Why doesn't Castle Black just copy staging configs to prod?

Architecture decision: production configs must be versioned with the code they deploy. This ensures data integrity and proper audit trail.

To roll back a production deployment:

1. Go to the argocd-app-config repository
2. Navigate to apps/{namespace}/{app-name}/prod/metadata.json
3. Change the targetRevision to the previous version you want to roll back to
4. Commit the change with a descriptive message like "Rollback app-name to version X.Y.Z"

ArgoCD will automatically detect this change and deploy the previous version within a few minutes. You can monitor the rollback progress in ArgoCD and Castle Black will reflect the changes once complete.

Alternative approach: You can also revert the specific commit that was created during the original promotion directly in GitHub.