Independent · 2026–present

Tellurion: a small deployment with explicit capabilities

Independent creator and owner

Tellurion is my independent Rust geospatial serving engine. It combines a small self-hosted deployment with capability-aware geospatial interfaces and public evidence that readers can inspect.

Systems architecture Geospatial & interoperability Cloud & DevOps
Sources & scopeDocument library

Problem: evaluate geospatial serving without a large platform

A geospatial server should be useful before an evaluator commits to a fleet of services. At the same time, a small default deployment should not hide the limitations of its storage and protocol implementations.

Tellurion starts from a native serving engine and an embedded GeoPackage path. The architectural challenge is preserving that accessible entry point while supporting other storage capabilities and inspectable data journeys.

Architecture: native serving, routed storage

The repository describes a Rust engine with OGC API and STAC surfaces, routed storage drivers and an embedded GeoPackage default. PostGIS is an optional storage choice for deployments needing its capabilities.

The public gallery preserves separate vector, raster and other demonstration journeys. A STAC discovery case connects a bounded WorldCover Item to GeoPackage and COG serving lanes, with provenance and live resources for inspection.

The architecture diagram deliberately separates protocol surfaces from storage capabilities. It does not imply every driver implements every query or format.

A native engine with distinct storage capabilities

Clients use geospatial interfaces through one native engine. GeoPackage provides an embedded path; PostGIS provides a separate database path; COG and other supported sources use capability-specific serving. Public demos illustrate bounded journeys rather than a uniform backend contract.

Open full-size SVG
Tellurion · native serving with explicit capabilitiesOne native Rust engine exposes geospatial API surfaces through configured storage drivers. GeoPackage is the embedded default; PostGIS is an optional database path; raster and file sources have their own capabilities. Tellurion · native serving with explicit capabilities Independent self-hosted engine · storage choice stays visible PROTOCOL SURFACES Named interfaces, not blanket certification Features / STAC Discovery and feature access Tiles / Maps / Styles Vector and raster views Evaluator Inspect public journeys resources requests NATIVE SERVING BOUNDARY Rust engine and storage capabilities Interface handling Request and response shape Storage routing Select a configured capable driver API request route STORAGE PATHS Different capability contracts Embedded GeoPackage Optional PostGIS COG / file sources embedded database source reads Each driver has its own supported operations. A gallery journey demonstrates a bounded case. The retained Rome measurement is a 0.2.0 smoke-scale benchmark; it is not a capacity claim for other builds. PROTOCOL SURFACES Named interfaces, not blanket certification NATIVE SERVING BOUNDARY Rust engine and storage capabilities STORAGE PATHS Different capability contracts Request / integration Message / asynchronous work Persistence / data access

Decisions: make evaluation boundaries visible

The embedded default reduces infrastructure requirements for evaluation. A database service remains a choice rather than a prerequisite for every run. Driver capability limits must be explained alongside the API surface.

The gallery includes source and evidence, retained version entry points and dated artifacts. A public walkthrough demonstrates an edited journey; it is not a throughput benchmark. Likewise, hosted response timings are affected by the demonstration environment.

For a retrospective architectural comparison, I would consider a deployment that always requires a database. It could simplify uniform server-side spatial behavior but increases the minimum setup. Tellurion’s embedded path makes that tradeoff visible to an evaluator.

Outcomes: self-hosted software and public journeys

Tellurion’s public source and demonstration gallery let readers inspect its serving approach. The independent project is distinct from FAO institutional work. Community source is offered under AGPL-3.0-only; the repository and release documentation define applicable terms.

The retained Rome result is a Tellurion 0.2.0 smoke-scale benchmark with its own method and caveats. It is not generalized to later releases or other datasets. Demonstrated standards behavior is not presented as certification or blanket conformance.

The project offers self-hosted software; it does not offer a Tellurion Cloud service or a service-level agreement.

Learning: a demo is stronger when its claim is bounded

A credible evaluator journey should identify the build, data source, interface and limitation. A short map preview can be valuable evidence of that journey while remaining insufficient evidence for general capacity or availability.

For a deployment decision I would measure the intended dataset, query mix and chosen driver directly, and verify unsupported capabilities explicitly rather than treating a successful gallery example as a universal guarantee.

Questions & discussion

Why use GeoPackage as the default?

It supports a self-contained entry point without a required database service. PostGIS remains a separate capability choice for more demanding workloads.

Read the relevant section
Do the demos prove full OGC conformance?

No. They evidence named behaviors and bounded journeys. Certification or general conformance requires a separately scoped assessment.

Read the relevant section
Can the Rome benchmark predict another deployment?

It is a retained 0.2.0 smoke-scale result. Its dataset, build, method and caveats apply to that measurement; another deployment needs its own benchmark.

Read the relevant section

Sources & scope