GeoServer hosting: your layers online, no server

Why publish with GeoServer

GeoServer is an open source map server written in Java. It publishes geographic data using OGC standards: WMS for map images, WFS for vector features, WCS for rasters and WMTS for tiles. It reads files (Shapefile, GeoPackage, GeoTIFF) and databases, including PostGIS, and applies SLD styles.

Its value lies in those standards: a layer published by GeoServer displays in QGIS, Lizmap, ArcGIS, Leaflet or OpenLayers with no conversion. That is why it is a common choice for sharing data with partners, feeding a web application or meeting an open data obligation. If you are still choosing between servers, read our comparison GeoServer, MapServer or QGIS Server. GeoServer is also a long-standing project with an active community, regular releases and extensive documentation, which matters when you plan to keep services online for years. Because it follows standards rather than a proprietary format, the investment you make in data, styles and service URLs is not tied to a single vendor or hosting provider.

The most common use cases

Before talking about GeoServer hosting, it is worth clarifying what the server will be used for. Real needs determine its size, the services to enable and the level of security. Here are the situations most often seen in consultancies, local governments and development projects.

• Sharing reference data with partners. Administrative boundaries, road networks, zoning: a stable WMS or WFS layer avoids emailing files at every update, and everyone sees the same version.
• Feeding a web application. A Leaflet or OpenLayers application built in house reads layers as WMS for display and as WFS for information popups, without storing the data itself.
• Meeting a publication obligation. Many open data programs and national infrastructures require services that follow OGC standards; GeoServer provides them without development.
• Sharing large rasters. Orthophotos, elevation models or scanned maps can be viewed as WMS or WMTS without users downloading gigabytes.
• Complementing a Lizmap portal. A GeoServer service can be added to a QGIS project, then displays in the map published with LizPack Map like any other layer.

If your need is only to publish a map built in QGIS, with its styles and print layouts, a Lizmap portal served by QGIS Server is often more direct. GeoServer makes the most sense when layers must live independently of any project and be consumed by a variety of tools. The two also combine very well: a portal for the general public, GeoServer services for technical partners, both fed by the same PostGIS database, with no data copies and no double updates.

What a self-hosted GeoServer requires

Installing GeoServer is well documented and within reach of any technician. Running it in production takes more, and over time:

• A Java runtime compatible with your GeoServer version, plus a servlet container if you do not use the standalone package.
• Memory. GeoServer needs several gigabytes as layers and users grow; tuning Java memory and the tile cache is part of the job.
• A domain name and an HTTPS certificate, renewed on time, with a reverse proxy in front of the application.
• Security: change the default administrator password, keep the admin console off the open Internet, set permissions per workspace.
• Updates. GeoServer regularly ships maintenance releases, some of which close serious vulnerabilities. Our guide securing and updating GeoServer explains why this matters.
• Monitoring and backups of the data directory, styles and database.

Installing GeoServer yourself: the main steps

To measure the real effort, here is the typical path of a production installation on a Linux server. Each step is documented on geoserver.org; it is the sequence, and keeping it maintained, that takes time.

1. Rent or prepare a machine with enough memory for GeoServer and the system, and a separate or backed-up disk for the data.
2. Install the Java version stated in the documentation for your chosen GeoServer version, then make sure no other version takes precedence.
3. Deploy GeoServer, either with the standalone package that ships its own web server, or as a WAR archive in a servlet container.
4. Move the data directory outside the installation folder, pointing to it with the GEOSERVER_DATA_DIR variable, so an update does not wipe it.
5. Tune the memory allocated to Java for the machine, then restart and check the status page in the console.
6. Put a reverse proxy in front of GeoServer with a domain name and an automatically renewed HTTPS certificate, and give GeoServer its public URL so GetCapabilities documents return the right addresses.
7. Replace the default credentials (admin and geoserver), create named accounts, close public access to the console.
8. Schedule backups of the data directory and the database, and monitoring that alerts you when the service stops responding.

Expect one to several days for a first clean installation, then a few hours a month for updates, monitoring and incidents. That time is the real cost of self-hosting, far more than the price of the machine. Document each step as you go, so that someone else on the team can reproduce or repair the installation when you are away.

GeoServer hosting: self-managed or managed

Self-hosting remains the right choice if you need specific GeoServer extensions, full server access or very large volumes. LizPack does not replace GeoServer: it hosts and maintains it. To keep control of the machine, LizPack Enterprise installs GeoServer on your own infrastructure.

Publish your first layer

With GeoServer Cloud, going live takes four steps and no command line:

1. From the LizPack dashboard, open GeoServer Cloud: your isolated workspace is created immediately.
2. Upload a zipped Shapefile, a GeoPackage or a GeoTIFF. If your data lives in a LizPack PostgreSQL and PostGIS database, link it to your workspace in one click.
3. Publish the layer as WMS, WFS or WMTS and pick its style in the GeoServer console.
4. Copy the service URL to use it in your tools.

If your data is in PostGIS, the guide publishing PostGIS as WMS and WFS with GeoServer walks through the store, the layer, the SLD style and the test in QGIS. Before publishing, give your layers simple names (lowercase, no spaces or accents): that name will appear in service URLs and in your users' software, and changing it later forces everyone to reconfigure their connections. Also check that the projection of your data is declared: a file without a known projection publishes poorly, or shows up in the wrong place.

Consume the service in QGIS, Lizmap or the web

Once published, the layer has one service URL per standard. In QGIS, open the Data Source Manager, WMS/WMTS or WFS tab, create a connection with that URL, then add the layer.

• QGIS: WMS for display, WFS to query or export features.
• Lizmap: add the service to your QGIS project, then publish the project; the layer shows up like any other.
• Leaflet, OpenLayers, ArcGIS: any client that reads OGC standards displays your layers.
• WMTS tiles: the built-in tile cache speeds up frequently viewed layers.

Prefer WMTS or WMS for a public map, and WFS when users need the attributes or the geometry. For WFS, also consider the volume: a client asking for every feature of a large table can be slow and heavy, so filter by extent or attribute whenever possible.

To share a layer with a partner, send the service's GetCapabilities URL rather than a screenshot or an export: they will always see the latest data, and their software will list the available layers, projections and styles on its own.

Common errors and how to fix them

Whether GeoServer runs on your premises or is hosted, the same difficulties come up when publishing or consuming a layer. Most are fixed in minutes once the cause is identified.

A useful habit: always test the layer in the GeoServer console preview before blaming the client. If the preview works, the problem lies in the URL, the projection or permissions on the client side; if not, it is in the publication itself. Keep a short internal note of the fixes you apply: the same issues tend to come back with each new dataset or new partner, and a shared checklist saves hours.

Sizing GeoServer and planning for the long run

Before choosing, estimate what you will actually publish. Three factors weigh more than the number of users: the type of data, the number of layers and how they are viewed. A vector layer of a few thousand features served as WMS costs little. An orthophoto mosaic of several gigabytes, queried at every scale, needs memory, fast disk and a well-tuned tile cache. A WFS open on a large table can saturate the server on its own if a client requests every feature at once.

• Heavy rasters: prefer tiled GeoTIFFs with overviews (pyramids), which read much faster than a raw image.
• Frequently viewed layers: serve them as WMTS from the tile cache rather than as WMS rendered on every request.
• Large tables: store them in PostGIS with a spatial index rather than in Shapefiles.
• Growth: watch data volume and the number of published layers; that is what moves you from a free tier to a quote, or from a small server to a bigger one.
• Response time: a map that takes several seconds to draw almost always points to an expensive style, a missing index or no cache, rarely to a lack of raw power.

Plan your exit from day one. GeoServer relies on standard pieces: data files or a PostgreSQL database, SLD styles, services at OGC URLs. If you change hosting, you export data and styles, recreate the layers, then share the new URLs with your users. So keep a copy of your SLD styles and a list of your published layers, whoever hosts you. With GeoServer Cloud, the data you upload remains yours, and a PostgreSQL and PostGIS database can be taken back with the usual PostgreSQL tools.

Which option to choose

If you publish a few dozen layers without special extensions, managed hosting saves you the server, Java, the certificate and the security watch. You keep a standard GeoServer: your SLD styles and service URLs stay valid elsewhere. Ask yourself three simple questions: how many layers and gigabytes will you publish within a year, who on the team could update the server in an emergency, and which extensions you cannot do without. If the answers are a few, nobody and none, managed hosting is the sensible choice.

If GeoServer is the core of a heavy data infrastructure with a dedicated systems team, self-hosting makes sense. To compare the total cost of each option, see our guide on the cost of an open source web GIS, and for the big picture, what LizPack does.

Frequently asked questions