Post-cutover 14-day observation window on DEV-474 closed today with 14/14 healthy days. This removes every RocksDB-era artefact from the manifest and updates the README to reflect the PostgreSQL backend as the default: - Delete PVC `stalwart-data` (was 20Gi hcloud-volumes-encrypted, RWO). - Drop the `fix-permissions` init-container (existed only to chown the RocksDB PVC mount). - Replace the StatefulSet's `data` volume with an `emptyDir` and keep the `/var/lib/stalwart` mount as a plain scratch path (Stalwart's state is now in the `stalwart-postgres` StatefulSet). - Delete the `stalwart-backup` CronJob and its `stalwart-backup` ServiceAccount / Role / RoleBinding — RocksDB snapshotting is obsolete now that state lives in Postgres. Daily backup is via `stalwart-postgres-backup` (restic tag `stalwart-postgres`). - README: update version, backend, storage, backup, files, and deployment sections; correct exposed-ports language to match SMTP 25/587 + IMAPS 993. Executed alongside the merge: - `restic forget --prune` removed all 11 snapshots on tag=stalwart (Job `stalwart-restic-forget-rocksdb` on 2026-08-28 15:09 UTC, log preserved on DEV-474). 16.165 MiB pruned. `restic snapshots --tag stalwart` now returns empty; only the 14 tag=`stalwart-postgres` snapshots remain. - `stalwart-backup` CronJob was pre-suspended in-cluster to prevent tonight's 03:00 UTC fire from re-creating a stalwart-tagged snapshot before this PR merges. Rollback (if needed before merge): revert this commit; the old CronJob would then re-create RocksDB snapshots from live PVC contents. After merge the rollback path is the Postgres `pg_dump` restic chain only. Refs: DEV-467, DEV-473 (cutover), DEV-474 (this observation + teardown), DEV-548 (day-14 execution issue). Co-Authored-By: Paperclip <noreply@paperclip.ing> |
||
|---|---|---|
| .. | ||
| argocd | ||
| basicstack-org | ||
| bookstack | ||
| directus | ||
| dozzle | ||
| forgejo | ||
| forgejo-runner | ||
| harbor | ||
| headlamp | ||
| monitoring | ||
| observability/patches | ||
| opencloud | ||
| pangolin | ||
| paperclip | ||
| passbolt | ||
| pocket-id | ||
| stalwart | ||
| app-argocd.yaml | ||
| app-basicstack-org.yaml | ||
| app-bookstack.yaml | ||
| app-directus.yaml | ||
| app-dozzle.yaml | ||
| app-forgejo-runner.yaml | ||
| app-forgejo.yaml | ||
| app-harbor.yaml | ||
| app-headlamp.yaml | ||
| app-opencloud.yaml | ||
| app-pangolin.yaml | ||
| app-paperclip.yaml | ||
| app-passbolt.yaml | ||
| app-pocket-id.yaml | ||
| app-stalwart.yaml | ||
| ARGOCD-MIGRATION.md | ||
| README.md | ||
Applications
This directory contains deployment configurations for all applications running on the basicstack.de cluster.
ArgoCD Application Management
Each application has two types of files:
app-<name>.yaml: ArgoCD Application manifest that tells ArgoCD to sync the app subdirectory<name>/: Application-specific Kubernetes manifests and configuration
The app-*.yaml files are synced by ArgoCD and create/manage the corresponding Application resources.
Each application's manifests in its subdirectory are then synced by its Application resource.
Structure
Each application should have its own subdirectory containing:
- Kubernetes manifests: Deployment, StatefulSet, Service, ConfigMap, Secret definitions
- Helm values: If using Helm charts, include values.yaml files
- Configuration files: Application-specific configs (TOML, JSON, YAML)
- Documentation: README or guide specific to the application deployment
- Patches: Any kubectl patches or modifications needed
Example: Stalwart
The stalwart/ directory serves as a reference implementation, containing:
- Multiple deployment variants (basic, with OIDC, etc.)
- Helm values files
- Monitoring dashboard configurations
- Backup/restore procedures
- Operational documentation
Adding a New Application
- Create a new directory:
apps/<application-name>/ - Add your Kubernetes manifests
- Include a README.md explaining:
- What the application does
- How to deploy it
- Configuration options
- Troubleshooting steps
- Test the deployment in a dev environment
- Commit with a descriptive message
Naming Conventions
- Directory names: lowercase, hyphen-separated (e.g.,
my-app) - Manifest files: descriptive names indicating resource type (e.g.,
deployment.yaml,service.yaml) - Use consistent naming across applications