Skip to content
getgeolens.com

Self-hosted Provider Notes

GeoLens self-hosts via Docker Compose, which is the supported install path. A community-maintained, unsupported Helm chart also exists for Kubernetes; if you run it on EKS, see Deploy on Amazon EKS. Production deployments commonly migrate the database to a managed PostgreSQL service (RDS, Cloud SQL, DigitalOcean Managed Database), storage to S3-compatible object storage, and cache to a managed Redis-compatible service (ElastiCache, Memorystore). The admin’s job at provisioning time is to wire the corresponding env vars correctly and ensure security-group / firewall rules permit outbound HTTPS to the chosen provider’s endpoints.

Backups intersect with managed-provider deployments in two places. First, managed PostgreSQL providers offer their own snapshot facilities (RDS automated backups, Cloud SQL backups, DO Managed Database snapshots). These are the recommended primary recovery mechanism because they use provider storage-layer snapshots. Second, the GeoLens backup service is still useful for application-level dumps when you need cross-version portability, such as upgrading from PostgreSQL 15 to 16 with logical-format dumps where a physical snapshot is version-locked.

Combine both: provider snapshots for primary recovery, GeoLens backups uploaded to S3 for offsite and cross-version archival. See Backups & restore for the GeoLens-side configuration.

TLS termination is typically handled at the load balancer or CDN layer; pick what fits your deployment. Cloud providers offer multiple managed paths: AWS Application Load Balancer with ACM, GCP Cloud Load Balancing, DigitalOcean App Platform’s automatic Let’s Encrypt, or self-managed Caddy/Traefik on a VM.

For the environment contract, the database bootstrap and the health endpoints, see Self-host on managed cloud services. The provisioning steps for AWS, Azure, Google Cloud and DigitalOcean live in geolens-deployments.