Earthbond Build And Access Manual
Purpose
This manual explains how the current Earthbond deployment is built, accessed, backed up, and defended operationally.
It is written for humans making the next decision about:
- whether the current deployment is understandable,
- whether the current backup boundary is correct,
- how PostgreSQL, MinIO, Docker, and the web app fit together,
- what is preserved in GitHub,
- what is intentionally excluded.
Access Points
Primary WAN access:
- app:
- upload workflow:
- manuals:
- admin gate:
Workspace Layout
The repository is now partitioned into explicit project views:
Earthbond remains the active deployment project.
projects/earthbond/core provides the Earthbond source view.
projects/earthbond/generated provides the Earthbond generated/backup view.
projects/wiicco-site isolates unrelated website/export assets from the deployment root.
The runtime remains Earthbond-only.
Canonical GitHub Source
Earthbond should be treated as its own GitHub deployment source:
- repository:
git@github.com:robby1312/earthbond.git
- active deployment branch:
main
The local server remains the runtime environment and should run from a local clone of this repository.
Deployment Shape
The deployment is built from:
- Docker Compose
- Python application services
- nginx and Caddy proxy layers
- PostgreSQL as the main relational truth store
- MinIO as raw object storage
- generated manuals and operational exports
Main source files:
- docker-compose.yml
- Dockerfile.python
- Dockerfile.web
- Dockerfile.edge
- Caddyfile
- edge.conf
- app-web.conf
Programming Languages
Main languages used:
PythonSQLJavaScriptbashYAML
Proxy Layers
The deployment uses multiple proxy layers:
- public TLS proxy:
- internal edge proxy:
- app-web proxy:
- API gateway:
PostgreSQL
PostgreSQL is used for:
- source registry
- canonical tables
- semantic projection
- audit records
- workflow state
- scoring outputs
The live schema is defined by migrations under:
MinIO
MinIO is used for immutable raw object storage.
It stores:
- uploaded raw payloads
- staged field-package objects
- evidence-pack style outputs where object persistence is needed
It does not hold:
- canonical relational truth
- auth state
- scoring logic
GitHub Backup Boundary
The GitHub backup is a source and configuration backup, not a raw data backup.
Included in the GitHub backup branch:
- Docker deployment source
- Python application source
- UI source
- docs and manuals
- schema migrations
- generated redacted Docker deployment config
- generated PostgreSQL schema-only backup
- generated MinIO manifest without objects
Excluded:
.envdata/minio/data/runtime/data/auth-outbox/data/external/- PostgreSQL row data
- MinIO objects
- runtime secrets
Backup Branch
The automated source backup is pushed to:
- remote:
git@github.com:robby1312/earthbond.git
- branch:
main
Local Git Workflow
The local working branch for Earthbond deployment operations should be:
main
This avoids mixing deployment history with unrelated local branches.
The GitHub backup job now expects the checked-out branch to match the configured target branch before it will push.
Backup Structure
Generated backup artifacts are stored in:
Structure:
- backups/README.md
backups/docker/configbackups/docker/images/manifestbackups/docker/images/ghcrbackups/postgres/schemabackups/minio/manifestbackups/repo/state
Backup Automation
Host automation:
Why The Backup Runs Outside Containers
The backup runs on the host because:
- the git working tree is on the host
- GitHub SSH credentials are host-bound
- the backup should not depend on container shell state
- the backup boundary should remain outside app credentials and runtime secrets
PostgreSQL Backup Meaning
The GitHub branch contains:
- schema-only export
- table inventory
- no row data
Script:
MinIO Backup Meaning
The GitHub branch contains:
- bucket manifest
- bucket names
- deployment storage shape
- no object payload data
Script:
Docker Backup Meaning
The GitHub branch contains:
- source Docker files from the repo
- generated resolved Compose output with secrets redacted
- current service list
- Docker image manifest separated from config
- optional GHCR push logs when image mirroring is enabled
Script:
Related Manuals
- Deployment Healthcheck Runbook
- Data Platform Storage And DB Manual
- Database Relationship Schematic
- Decision Defense Report
Operational Conclusion
The current Earthbond backup approach preserves:
- deployment source
- database structure
- object-store structure
- access/build documentation
It intentionally does not preserve:
- secrets
- runtime datasets
- raw MinIO payloads
- PostgreSQL row data