Generated complete OpenCloud config using 'opencloud init' and created
comprehensive sealed secrets for all 27 required configuration values.
## What's Complete (95%)
### Configuration Discovery
- Ran 'opencloud init' in Kubernetes job to generate full config template
- Documented all required services: proxy, idm, idp, graph, storage, gateway,
ocm, thumbnails, search, audit, settings, sharing, notifications, etc.
- Created complete opencloud.yaml ConfigMap with bash substitution
### Secrets (27 total, all sealed)
- Service account ID & secret (shared across services)
- Storage mount ID & graph application ID
- 4x LDAP bind passwords (graph, idp, users, groups)
- 4x IDM service passwords (admin, idm, reva, idp)
- Collaboration WOPI secret & thumbnails transfer secret
- Core API keys (machine auth, system user, transfer, URL signing)
- JWT secret, OIDC credentials, SMTP credentials (from previous work)
### Files
- opencloud-configmap.yaml: Complete config with ${VAR} substitution
- opencloud-config-sealed.yaml: All 27 secrets sealed
- opencloud-config-secrets-complete.yaml: Unsealed reference
- init-job.yaml: Helper to run 'opencloud init'
- DEPLOYMENT_STATUS.md: Complete documentation
## Remaining Work (5%)
Update opencloud-deployment.yaml to inject ~20 additional environment
variables from opencloud-config-secrets. Template provided in
DEPLOYMENT_STATUS.md. Estimated time: 5-10 minutes.
## Technical Approach
OpenCloud's 12-Factor config system:
1. Config file provides structure (/etc/opencloud/opencloud.yaml)
2. Environment variables override values (highest precedence)
3. Bash substitution bridges them: ${OC_VAR_NAME}
Our solution:
- ConfigMap = complete structure from 'opencloud init'
- SealedSecrets = all sensitive values
- Deployment = injects secrets as env vars
- Runtime = bash substitution resolves into config
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
||
|---|---|---|
| apps | ||
| docs | ||
| infrastructure | ||
| .gitignore | ||
| README.md | ||
stack.basicstack.de
CD/CI deployment manifests and configurations for the basicstack.de Kubernetes cluster.
Repository Structure
stack.basicstack.de/
├── apps/ # Application deployments
│ ├── stalwart/ # Stalwart mail server (example)
│ └── forgejo/ # Forgejo Git service (placeholder)
├── infrastructure/ # Infrastructure-level configurations
│ ├── networking/ # Network policies, ingress, DNS
│ └── monitoring/ # Monitoring, logging, observability
└── docs/ # Documentation and guides
Purpose
This repository serves as the central source of truth for all deployment configurations targeting the basicstack.de Kubernetes cluster. It follows GitOps principles where infrastructure and application state is declaratively defined and version-controlled.
Directory Details
apps/
Contains deployment configurations for individual applications and services running on the cluster. Each application should have its own subdirectory with:
- Kubernetes manifests (Deployments, StatefulSets, Services, etc.)
- Helm values files
- Configuration files
- Application-specific documentation
Example: The stalwart/ directory contains the complete deployment configuration for the Stalwart mail server, including multiple deployment variants, monitoring setup, and operational guides.
infrastructure/
Contains cluster-wide infrastructure configurations:
- networking/: Ingress controllers, network policies, DNS configurations, load balancers
- monitoring/: Prometheus, Grafana, logging infrastructure, observability tools
docs/
General documentation including:
- Deployment procedures
- Cluster architecture
- Troubleshooting guides
- Best practices
Getting Started
- Clone this repository
- Review the example Stalwart deployment in
apps/stalwart/ - Follow the pattern for new application deployments
- Ensure all manifests are tested before committing
Contributing
All changes should be:
- Committed with clear, descriptive messages
- Tested in a development environment when possible
- Documented appropriately
- Reviewed before deployment to production
Cluster Information
- Cluster: basicstack.de
- Platform: K3s on Hetzner Cloud
- Namespace Strategy: One namespace per application (recommended)
- Ingress: Traefik (default K3s ingress controller)