Why Self-Host Your Survey Data (and How Open Source Makes It Possible)

Survey data is not like most business data. A boundary observation from 2026 may be the deciding evidence in a dispute in 2046. As-staked records prove what your crew set and when. Clients pay for this data, courts rely on it, and licensing boards expect you to keep it. Which raises an uncomfortable question: if all of it lives in a vendor's cloud, do you actually control it?

Survey data is evidence, and it belongs to your clients

Two properties make survey data unusually long-lived. First, it is legal evidence: monuments get destroyed, sites get rebuilt, and the record of an observation, with its datum, epoch, fix quality, and date, is often the only durable account of where something was. Second, much of it is ultimately client property or professional work product you are obligated to retain and reproduce, sometimes decades later.

"Decades" is the key word. Software subscriptions are priced and architected in quarters. Betting a 20-year retention obligation on a 12-month subscription is a mismatch worth taking seriously.

The real risks of a vendor-locked cloud

None of this requires assuming bad faith. Ordinary business behavior is enough:

• Pricing changes. Per-seat prices climb, features migrate into higher tiers, and your archive becomes leverage in the renewal conversation, because leaving means figuring out how to move it.
• Export limits. Some platforms export points readily but drop the metadata that made them defensible: fix type, RMS values, correction age, photos, attribute history. A CSV of coordinates is not the same record as the observation that produced it.
• Service shutdown. Products get discontinued and companies get acquired. A sunset notice with a 90-day export window is a bad week for a firm with ten years of projects in that system.
• Access as a subscription. In some models, letting a subscription lapse means losing the ability to even read your own historical projects.

Hosted clouds are genuinely convenient, and for many firms they are the right operational choice. The problem is not the cloud; it is a cloud you cannot leave.

What self-hosting actually means

Self-hosting sounds enterprise-scary and mostly is not anymore. In practice it means running the vendor's server software on hardware you control: an office machine, a rented virtual server, or your company's existing infrastructure. The modern shape of this is a Docker Compose stack: one configuration file that starts a few coordinated services, typically:

• Postgres with PostGIS, the open-source spatial database that already underpins much of the GIS world, holding points, linework, and attributes;
• Object storage for the heavy files: photos, DXFs, LiDAR scans, and Gaussian splats;
• The application server that the field app and browser workspace talk to.

One command brings it up; standard database dumps and file copies back it up. Anyone comfortable administering a CORS connection and a plotter can run it, and if the vendor vanishes tomorrow, your server keeps running and your data stays queryable in an open database.

Open-source field GIS already proved this works

This is not a hypothetical model. In open-source field GIS, self-hosting is normal: QField (GPL, QGIS-first) offers QFieldCloud with a self-hostable server, and Mergin Maps (GPL/AGPL, also QGIS-first) does the same. Both projects run hosted clouds for convenience while publishing the server so organizations with data-sovereignty requirements, or simple caution, can run their own. Surveying deserves the same option, arguably more, given the legal weight of the data.

What to look for in any platform

The "feature ransom" test matters even if you never self-host: a vendor that gates stakeout or linework behind a subscription tier is showing you how it thinks about leverage. And exports are the escape hatch you should test before you need it: export a real project, re-import it elsewhere, and see what survived.

What OpenSurvey3D ships now — and what remains ahead

The native app already follows the parts of this architecture that can stand on their own:

• Projects, observations, photos, scans, offline maps, and built site models are local to the device and require no account.
• Exports are open and inspectable: CSV, GeoJSON, DXF, LandXML, PDF/HTML QA, terrain OBJ, and a project ZIP that carries supporting files.
• The native Swift project is published under the MIT license, including the GNSS, database, QA, and export paths.

The synced browser workspace and self-hosted team backend are still roadmap items; there is no server package to deploy today. The intended direction remains a self-hostable stack rather than a privileged cloud-only edition. Until that ships, the durable handoff is the local project plus open files an office can store on infrastructure it already controls.

The field side follows the same philosophy: supported Emlid Bluetooth receivers and any rover streaming NMEA over Wi-Fi TCP, plus a built-in NTRIP client, so your hardware and correction sources are not tied to one data silo. If the record you sign needs to be readable in twenty years, open files and explicit coordinate metadata are the first line of defense.