On-premise GIS: your maps on your servers

Why a sovereign GIS

A hosted web GIS is the simplest option for most organizations. But some data must not leave its owner's infrastructure: cadastre and land records, sensitive networks, personal data, defense, health. Sometimes it is the law, sometimes internal policy, sometimes a requirement from a funder or a public tender.

• Control of location: data stays in your data center or with the hosting provider you chose.
• Control of access: staff sign in with their usual account, and the security rules are yours.
• Control of timing: you decide when an update is applied.
• Continuity: the service does not depend on an outside provider staying in business.

Sovereignty does not mean isolation. A GIS installed on your premises can publish maps open to the public, serve WMS feeds to partners or exchange data with a national infrastructure. The difference lies in who decides: you choose what goes out, and nothing goes out by default. In practice, many agencies keep their reference data internal and publish only selected, approved layers, which is easier to justify to auditors than a blanket transfer to a third party.

Hosted or on premises: a decision grid

Choosing between a hosted GIS and an on-premise GIS is rarely settled by a single argument. This grid helps you ask the question methodically, with legal, IT and business teams around the same table.

If most answers fall in the right-hand column, an on-premise GIS is justified. If they are split, start with a hosted offer for public maps and keep sensitive data in house: both approaches run the same open source software and can coexist.

What an on-premise GIS really takes

Installing Lizmap, QGIS Server, PostGIS or GeoServer on an internal server is entirely possible: they are well-documented open source projects. The hard part comes after installation, when the whole stack has to run in production for years.

• A properly sized server: CPUs, memory and fast disks matched to the number of maps and the volume of imagery.
• A directory: staff do not want yet another password; the GIS must recognize Active Directory, LDAP or OpenID Connect accounts.
• Fine-grained permissions: who sees which map, who edits which layer.
• Backups: scheduled, copied off the server, and tested.
• A recovery plan: knowing how to rebuild the service on a new server after a major failure.
• Updates: compatible versions of QGIS, QGIS Server and Lizmap, and security fixes applied on time.

To weigh the real effort of a do-it-yourself install, read host Lizmap or install it yourself; for the budget, what an open source web GIS costs.

LizPack Entreprise: on-premise GIS without building it all

LizPack Entreprise is LizPack's open source geospatial infrastructure, the same as the hosted offer, installed on a server you control. It does not replace the open source software: it installs Lizmap, QGIS Server, PostGIS, GeoServer and, if your license includes it, field data collection with QField, then manages them from a single portal.

• Lizmap instances: as many as your license allows, each with QGIS Server and its PostGIS database.
• Sign-in through your directory: Active Directory, LDAP or OpenID Connect (Entra ID, Keycloak), with roles, groups and per-map access.
• Backups and recovery: scheduled backups, copies to your S3 storage, and full rebuild on a new server.
• GeoServer and data: built-in GeoServer and an inventory of your instances' data, with their records.
• [LizPack Field](/lizpack-field): field collection with QField on the same server, if your license includes it.
• Your branding: the portal carries your name and logo; your data never leaves your infrastructure.

Directory, roles and per-map permissions

Directory sign-in is often what gets a GIS accepted internally. Staff keep their usual username, and IT keeps control of the accounts. Two families of protocols coexist, and LizPack Entreprise supports both.

• LDAP and Active Directory: the portal queries the directory to check the password and read the user's groups. This is the most common case in public agencies running Windows workstations.
• OpenID Connect: the user is redirected to the organization's identity provider, such as Entra ID or Keycloak, which confirms their identity. The password never passes through the GIS, and any multi-factor authentication configured at the provider applies automatically.

Once the user is recognized, you still have to decide what they can see. Best practice is to think in groups rather than individuals: a Planning group, a Utilities group, an Elected Officials group. Each map is opened to one or more groups, and staff arrivals and departures are handled in the directory, without touching the GIS.

1. List the planned maps and, for each one, who needs to view it and who needs to edit it.
2. Group these needs into a few business groups, aligned where possible with groups already in the directory.
3. Assign a role to each account in the portal, then open each map to the relevant groups.
4. Check with a test account from each group before opening access to staff.

Server, network and certificates

LizPack Entreprise requires an x86_64 processor (ARM servers are not supported), Ubuntu 22.04 LTS or 24.04 LTS with administrator access, an NVMe or SSD disk, and ports 80 and 443 open.

GeoServer alone reserves 4 to 8 GB of memory, and LizPack Field needs 6 GB more. If in doubt, contact us before ordering your server.

An on-premise GIS is still a web service: its security starts with the network. LizPack Entreprise requires ports 80 and 443 to be open to the server; the rest depends on your policy.

• Choose the exposure. A staff-only GIS can be reachable only from the internal network or the VPN. Public maps require Internet exposure, ideally behind the proxy or web application firewall your organization already uses.
• Plan the names. Reserve the domain names for the portal and the map sites early with your DNS team: in a public agency this is often the slowest step.
• Encrypt everywhere. All connections should use HTTPS, including internal ones. A certificate from a public authority suits a name exposed to the Internet; for a purely internal name, the organization's own certificate authority works, as long as workstations trust it.
• Restrict administrative access. Administrator access to the server should be limited to a few workstations and a few people, using keys rather than passwords.

Write these choices down in a short architecture document: IT security will use it to approve the project, and the team that later takes over operations will rely on it.

Setup, step by step

1. Describe your needs: number of maps, accounts, field collection.
2. Order or reserve a server that meets the requirements.
3. Install the portal with your license, then create the first administrator account. The portal manager, a free download for Windows, installs and updates the portal on your Linux servers from your workstation.
4. Create your instances, connect your directory and publish your projects with LizPack Publisher.

Internet access is needed to install and update. Day to day, users' workstations only need to reach your server. You run updates yourself from the portal, when you decide. The enterprise edition is priced by quote, based on the number of instances, accounts and the products included in the license.

If the project goes through a public tender, the specification should set verifiable requirements rather than a list of software: data stored on the buyer's infrastructure, sign-in through the existing directory (LDAP, Active Directory or OpenID Connect), permissions per map and per group, scheduled backups with an off-server copy, a documented procedure to rebuild on a new server, updates triggered by the buyer, and open formats for projects, databases and services. Also ask bidders for a restore demonstration and the exact server configuration they recommend. These criteria let you compare very different offers, and they protect the organization the day it changes provider, since QGIS projects, PostgreSQL databases and OGC services remain readable by other tools. Finally, ask how knowledge will be transferred to your own staff, because an on-premise GIS that only the vendor understands is not truly yours. A short training plan for your administrators, written into the contract, completes these requirements.

Running a sovereign GIS day to day

Once the portal is installed, sovereignty depends on operating habits. A few simple rules make the difference between a reliable on-premise GIS and a server nobody dares to touch.

• Test restores, not just backups. A backup that has never been restored is only a promise. Schedule a test restore at regular intervals, ideally on a test server.
• Keep a copy off the server. A copy on the same disk disappears with it. Copying to your S3 storage protects against losing the whole machine.
• Handle departures through the directory. When someone leaves the organization, disabling their directory account also cuts their GIS access, with no separate list to maintain.
• Schedule updates. Pick a quiet window, notify users, and take a backup just before.
• Write down the recovery procedure. Who does what if the server fails, where the backups are, how to rebuild on a new server: one page is enough, as long as it exists before the incident.

These rules apply to any self-hosted GIS. LizPack Entreprise provides the tools (scheduled backups, copies to S3, rebuild on a new server, directory sign-in), but the organization that puts them to work is still yours.

Common mistakes in on-premise GIS projects

The same pitfalls come up from one project to the next. Knowing them in advance saves weeks of delay. Most of them are easy to avoid when they are planned for early on.

• Undersizing the server. GeoServer alone reserves several gigabytes of memory, and imagery fills a disk quickly. Starting from the recommended profile rather than the minimum leaves room for new maps.
• Choosing a spinning disk or an ARM server. Both are ruled out by the requirements: the disk must be NVMe or SSD, the processor x86_64.
• Forgetting Internet access for installation. The server must reach the Internet to install and update, even if users do not need it afterwards. Have that flow opened before installation day.
• Connecting the directory last. If maps are built with local accounts and migrated later, permissions must be redone. Connect the directory from the very first maps.
• Never restoring. The first restore should not happen on the day of the outage.
• Relying on a single person. An internal GIS needs at least two administrators who know how to update and rebuild it.

When to stay with a hosted offer

On-premise GIS is not always the right answer. If you have no team to watch over a server, if your data is not sensitive, or if you are starting with a handful of maps, a hosted offer such as LizPack Map, LizPack's Lizmap hosting, is simpler and cheaper. Both run the same open source software, so you can move from one to the other. To place these choices against proprietary products, see ArcGIS Online alternatives.

Frequently asked questions