Run GIS in
your cloud.
Honua turns the GIS serving tier into familiar cloud infrastructure. Run the same OCI image with Docker or the public Helm chart, keep operational data in PostGIS, and send telemetry to the tools your platform team already uses. You choose the account, network, region, and scaling policy.
Modernize the serving tier.
Keep the infrastructure you trust.
Honua fits into a normal platform architecture, so GIS does not need its own isolated operating model.
Add capacity where the workload needs it.
Start with one container, then add serving replicas as traffic grows. Multi-node deployments use shared storage and Redis so coordination remains explicit. Put finite tile and artifact keys behind your CDN, and size PostGIS independently for the data and query load.
Pick the runtime that fits the traffic.
Send heavy jobs somewhere else.
Steady traffic and spiky traffic want different runtimes, and long-running geoprocessing wants neither. Honua separates the serving tier from batch compute so each one scales on its own terms. Infrastructure-as-code for these patterns ships as Terraform modules available to customers through support.
Runtime requirements and a measured datapoint.
Honua does not publish a requests-per-pod sizing rule. What exists publicly is one measured datapoint with a disclosed profile — a dated historical snapshot that cannot be independently reproduced exactly (the benchmark page states its own limits) — and the billing ceiling that bounds a serving unit. Use them as rough anchors, then validate against your own workload.
# Illustrative only — mirrors the disclosed GeoBench container profile
# (4 CPU cores, 4 GB memory). Not a recommendation or a guarantee;
# validate against your own workload during a pilot.
# Helm values / Kubernetes container resources:
resources:
requests:
cpu: "4"
memory: "4G"
limits:
cpu: "4"
memory: "4G"