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.

Open Survey's plan: self-hostable from day one

Open Survey is being built with this architecture as a founding constraint, not a retrofit. The plan:

• The web workspace is self-hostable via Docker Compose, backed by Postgres/PostGIS, from day one. The hosted cloud we run is pure convenience, the same software, not a privileged version.
• The workspace is local-first: you can use the browser tools with no account at all, dragging CSV, DXF, or GeoJSON onto a map.
• Exports are open and complete: CSV (PNEZD), GeoJSON, KML/KMZ, DXF, and GeoPackage, with datum and epoch stamped on every file and full observation metadata preserved.
• The software is free and open source, including the features that are commonly paywalled elsewhere.

The field side follows the same philosophy: receiver-agnostic Bluetooth NMEA support and a built-in NTRIP client, so your hardware and corrections sources are as unlocked as your data. If the record you sign your name to needs to be readable in twenty years, the safest place for it is a database you control, in formats anyone can open.