Registry and runtime profile
Set private or public image repositories, pinned version tags, image pull secrets and the lean or full backend profile. Air-gapped sites can mirror artifacts into an internal registry.
Customer-operated infrastructure
Self-hosted means inside your boundary.
Deploy 3DGeoServEngine in your cloud account, data center, private network, edge node or disconnected environment. The core server, web interface and service endpoints run without a mandatory Tech Maven-hosted control plane or vendor cloud subscription.
Deployment formats
Choose the smallest operational footprint that meets the mission.
The artifacts use the same headless server lifecycle and browser-facing service contracts. The differences are packaging, dependency footprint, process supervision and how infrastructure configuration is promoted.
| Format | What is deployed | Best fit | Operational boundary |
|---|---|---|---|
| Native server binary | Headless server executable with an explicit configuration and persistent data directory | Compact bare-metal, VM and edge installations | The operator supplies service supervision, TLS/reverse proxy, identity integration, logs and backup |
| DEB / RPM | Native Linux package plus service definitions and install lifecycle for Debian/Ubuntu or RPM-oriented distributions | Managed Linux fleets using existing package repositories and systemd operations | Package automation installs the service; environment-specific secrets, networking and backup remain operator concerns |
| Alpine Linux APK | Alpine package with OpenRC-oriented service integration | Small Alpine-based servers and controlled edge appliances | APK is the Alpine Linux package format, not an Android application package. |
| Docker lean image | Core backend without the optional embedded Python capability runtime | Feature, map, tile, imagery, catalog and other core service workloads with the smallest container dependency set | Mount persistent data and inject configuration; route traffic through the organization’s proxy or ingress |
| Docker full image | Core backend plus the curated Python capability service and its geospatial/scientific dependencies in the same backend container | Conversion, raster, WhiteboxTools, LiDAR, document generation and scientific Python routes | Heavy AI frameworks and GPU support require a customized image; the Python process is supervised with the backend workload, not presented as an independently scaled Kubernetes pod |
| Docker Compose | Coordinated backend and browser web containers, persistent storage and service networking | Single-node pilots, private servers, labs and repeatable integration environments | Compose provides process orchestration, not a substitute for production identity, secrets, monitoring or backup design |
| Helm / Kubernetes | Parameterized web and backend workloads, Services, optional Ingress, persistent storage, health probes and policy controls | Existing Kubernetes platforms operated by the customer or an authorized partner | Backend state is single-writer today; default to one backend replica and scale vertically unless state is deliberately redesigned or externalized |
| Terraform | A reusable module that installs the Helm release into an existing generic Kubernetes, EKS, AKS or GKE cluster | Infrastructure-as-code promotion across controlled environments | The module deploys the application to a reachable cluster; it does not claim to build the entire cloud account, network or cluster |
Lean versus full
Python is a capability choice, not a prerequisite.
The core service stays compact for environments that do not need the Python tool surface. The full image adds the specialist runtime while retaining one backend deployment unit.
LEAN
Start with the core service plane
Use the core server for protocol endpoints, catalogs, databases, dynamic vector tiles, local imagery services, remote COG range-read components, real-time services and browser applications without carrying a Python environment.
FULL
Add the curated Python capability service
Select the standard full image for conversion, raster, WhiteboxTools, LiDAR, document-generation and related scientific routes. Build a customized full image with the required extras and GPU/runtime support for heavy AI or ML frameworks.
ONE
One backend workload boundary
In the current container topology, the core backend supervises and communicates with the Python capability service inside the same backend container. Health, lifecycle and resource sizing must account for both processes.
EXT
External workers remain possible
Organization-specific Rust, Java, .NET, Python, GPU or proprietary services can use versioned HTTP/job contracts and portable artifacts through the platform’s broader extension seams.
Helm and Terraform automation
Repeat the application deployment without pretending every environment is identical.
The chart and Terraform module expose the operational decisions that vary between organizations. They automate application resources in an existing cluster while leaving cloud landing-zone, network, identity and compliance design explicit.
Services and optional Ingress
Configure internal Services, host/path routing, ingress class and TLS secret references. The deployment can sit behind the customer’s nginx, Traefik, cloud load balancer or identity-aware proxy.
Configuration without baked credentials
Reference existing Kubernetes Secrets for credentials and tokens, and use ConfigMaps or chart values for non-sensitive settings. External secret operators and vault products remain environment choices.
Persistent data is explicit
Bind the backend data directory to a persistent volume with a defined storage class, access mode and capacity, or connect services to governed external databases and object stores.
Readiness and liveness
Use the unauthenticated /healthz contract for orchestration probes, then add external checks for representative service endpoints, storage dependencies and user journeys.
Resources and workload controls
Set CPU/memory requests and limits, security context, service account and optional network policy. Scale the stateless web tier separately; keep the stateful backend at one replica unless its data architecture supports more.
Kubernetes topology
Separate ingress, presentation and state without hiding dependencies.
A production release should make request routing and durable state visible to operators.
Customer edgeDNS and TLS policyIngress / load balancerSSO or identity-aware proxyNetwork and WAF controls
3DGeoServEngine releaseBrowser web workloadSingle-replica backend workloadLean or full runtime profileServices and health probes
Governed state and sourcesPersistent data volumePostGIS / SQL Server / OracleS3 / Azure Blob / GCS / OneLakeLogs, metrics and backups
Scaling boundary: the current backend data directory is stateful and single-writer. Kubernetes provides scheduling, restart, rollout and configuration consistency; it should not be marketed as active-active backend high availability. Horizontal backend scaling requires workload-specific validation and a state architecture designed for it.
Operations that survive the demo
Deployment is complete only when state, security and recovery are owned.
The automation establishes a repeatable baseline. Production readiness depends on the controls connected around it.
| Concern | Platform/deployment hook | Operator decision and evidence |
|---|---|---|
| Identity and access | Bearer-token API controls, configurable CORS and integration behind an identity-aware proxy | Define user/service identities, token rotation, least privilege and authentication tests for every protected route |
| TLS and ingress | Optional application TLS plus reverse-proxy/Ingress termination patterns | Choose certificate authority, renewal process, approved protocols, DNS and externally verified routes |
| Persistent state | Configured data directory/PVC plus external database and object-store connections | Document what is authoritative, snapshot/backup frequency, restore procedure and recovery objectives; prove a restore |
| Observability | /healthz, service logs and workload health | Centralize logs and metrics, alert on user-impacting failures and include storage/network dependencies in synthetic checks |
| Resource sizing | Lean/full image choice and configurable CPU/memory requests and limits | Load-test representative vector, raster, 3D, real-time and Python jobs; size by workload rather than endpoint count |
| Upgrade and rollback | Versioned packages/images, Helm values and Terraform state | Pin versions, snapshot state, test schema/data compatibility and rehearse rollback before production promotion |
Disconnected preparation
No mandatory vendor cloud does not mean zero preparation.
Core service operation can run in a disconnected environment, but every required artifact and data dependency must cross the boundary deliberately.
01
Mirror software artifacts
Stage the selected native packages or container images, Helm chart, required Terraform providers/modules and their integrity metadata in approved internal repositories.
02
Pre-stage runtime dependencies
Bundle the web assets, Python environment when selected, models, GDAL data and any DuckDB spatial/cloud extensions the mission uses. Some optional extensions may otherwise attempt a first-load network download.
03
Stage operational data
Copy GeoPackage, MBTiles, PMTiles, COG, GeoParquet, catalog metadata and other approved sources needed when remote databases or object stores are unreachable.
04
Exercise the isolated path
Install, restart, restore and run representative map, service and analytical tests with external network access disabled before fielding the environment.
Automation scope is intentionally explicit.
Terraform targets an existing Kubernetes cluster, including generic Kubernetes plus existing EKS, AKS and GKE environments. Helm configures the 3DGeoServEngine release. Neither artifact is represented as a certified architecture, a one-click production environment or a replacement for cloud account, network, identity, security and recovery engineering.