GeoLibre 2.3: Can It Replace Google Earth Pro?

Google Earth Pro remains useful, but Google now says the desktop installer will stop being available for download on June 25, 2027. GeoLibre 2.3 arrives at the right moment: it opens KML, raster, vector, 3D, and cloud-native geospatial data in a browser, desktop app, Android app, or Jupyter notebook while keeping many workflows on the user's device.

It is not yet a drop-in replacement for Google Earth Pro, and it is much less mature than QGIS.

OpenSourceChoice verdict: GeoLibre is ready for a bounded evaluation by teams that need a portable, browser-first viewer and light GIS workbench. Keep QGIS as the production baseline for complex editing, topology, repeatable geoprocessing, and long-lived regulated workflows. Do not expose GeoLibre's default Docker image publicly without hardening it, and do not treat "local-first" as "no network traffic."

Methodology: This is a researched analysis of GeoLibre 2.3.0, its current documentation, repository history, release artifacts, CI configuration, privacy policy, packaging, and relevant Google Earth and QGIS documentation as observed on July 29, 2026. OpenSourceChoice did not perform a hands-on GIS workflow, code audit, penetration test, or performance benchmark.

Why this matters now

The timing is supported by more than one launch post:

• GeoLibre was among GitHub's daily trending repositories on July 29, with active upstream commits on the same day.
• Two high-engagement July discussions in the GIS community about Google Earth Pro's desktop transition repeatedly identified GeoLibre as an open-source alternative. Users also raised useful objections about KML behavior, project youth, and security.
• The current stable GeoLibre release, version 2.3.0, was published on July 25 with signed GitHub metadata and installers for desktop and Android platforms.
• Google's own help page now states that Google Earth Pro for desktop will no longer be downloadable after June 25, 2027. The current direct installer is version 7.3.7.

These signals do not prove product quality. They do establish a real decision window: organizations that depend on a free desktop globe now have enough time to inventory their workflows and test alternatives before the download deadline.

What GeoLibre actually provides

GeoLibre uses one React and TypeScript application across several shells:

1. Web and PWA: MapLibre GL JS renders the map in the browser. DuckDB-WASM, Turf.js, Pyodide, and other WebAssembly components handle many local data and processing tasks.
2. Desktop: Tauri adds filesystem dialogs, local MBTiles and raster access, native HTTP requests, project save/open, and an optional local Python processing sidecar.
3. Android: the same interface is packaged as a native Android app. Version 2.3 ships APK assets for multiple architectures.
4. Jupyter: the geolibre Python package embeds the application and synchronizes changes between the map UI and Python.
5. Self-hosted web: an official container serves the browser app through nginx and bundles a Python sidecar for additional conversion and Whitebox tools.

The map layer combines MapLibre for core 2D rendering, deck.gl for advanced overlays, and an optional CesiumJS globe. GeoLibre can load common local files and remote services, including GeoJSON, KML/KMZ, GeoPackage, GeoTIFF/COG, PMTiles, WMS, WFS, ArcGIS services, LiDAR, Zarr, 3D Tiles, and several cloud catalog formats.

That breadth is the project's strongest argument. A non-specialist can open a KML file, add a cloud-optimized raster, style a layer, inspect attributes, run spatial SQL, and share a project without first deploying a conventional GIS server.

It also creates a large test surface. "Supports a format" does not guarantee that a complex production file preserves every layer, style, CRS, attachment, time property, or embedded model exactly as another application does.

GeoLibre is closer to a light GIS workbench than a Google globe clone

Google Earth Pro and GeoLibre overlap, but their foundations are different.

GeoLibre does not include Google's imagery rights, Street View network, historical archive, search corpus, or service guarantees. Some integrations can connect to Google Earth Engine or Google 3D Tiles, but that reintroduces provider credentials, terms, quotas, and network dependency.

The practical conclusion is narrower than "replace Google Earth." GeoLibre can replace a subset of Google Earth Pro workflows built around KML/KMZ viewing, open basemaps, custom layers, lightweight analysis, presentations, and portable project files. It should not be assumed to replace imagery-dependent, historical-imagery, Street View, or highly polished tour workflows without a dataset-by-dataset test.

Version 2.3 is substantial, but the release cadence is a risk

Version 2.3.0 adds or improves typed coordinate search, delimited text in arbitrary coordinate reference systems, layer-style copy and paste, time-slider support for STAC and MosaicJSON sources, more processing tools, Android packaging, raster metadata, plugin handling, and multiple AI provider profiles.

The project is moving unusually fast. Its repository was created on May 27, 2026, and published 24 non-prerelease tags through version 2.3.0 by July 25. Git history observed on July 29 showed 320 commits since July 1; 263 were authored by project founder Qiusheng Wu. The GitHub contributor summary likewise remained heavily concentrated around one maintainer.

Those numbers are not a quality score. They reveal two operational facts:

• Upgrade churn is high. A team adopting today should expect behavior, schemas, plugins, and deployment guidance to change quickly.
• The bus factor is low. Community contributions exist, but design knowledge and delivery remain highly concentrated.

For a production team, a high version number is therefore misleading. GeoLibre 2.3 is roughly two months old, not a product with years of compatibility history.

There is also version skew between distribution channels. The desktop and GitHub release line is at 2.3.0, while the verified PyPI package observed on July 29 remained at 2.1.0 from July 14. Jupyter users should test the package they can actually install, not infer parity from the desktop release notes.

Local-first privacy has explicit network boundaries

GeoLibre's privacy policy says the desktop app does not require an account, collect telemetry, or upload local files by default. Local vector and raster data can be processed on-device, with a Python helper bound to 127.0.0.1 for heavier tasks.

Optional features still send data elsewhere:

• basemap providers receive tile requests derived from the current view;
• geocoding providers receive searched place names or addresses;
• configured AI providers receive prompts plus layer names and attribute field names;
• cloud catalogs receive queries;
• real-time collaboration sends project data, including locally loaded GeoJSON, through an OpenGeos relay on Cloudflare;
• Project → Share uploads the .geolibre.json project to share.geolibre.app and returns a public URL.

Project files can contain layer sources, styles, plugin state, preferences, and environment variables. A team must inspect a project before sharing it and must decide which data may cross each provider boundary.

An effective restricted-data profile should disable AI, collaboration, public sharing, geocoding, and unapproved remote basemaps. A packet capture during the pilot should confirm that this configuration produces only the expected requests. Privacy documentation is a starting point, not a substitute for an egress test.

Security is improving faster than governance

The repository has positive controls:

• CI blocks high and critical npm advisories in production dependencies.
• Dependabot is configured.
• Playwright smoke tests and a broader frontend, Rust, and Python gate run in CI.
• Tauri uses a host allowlist in its Content Security Policy.
• desktop file access is limited to paths selected through dialogs.
• the Docker sidecar uses a per-container token and confines conversion paths to /data by default.

Important gaps remain:

• The repository has no SECURITY.md or documented private vulnerability-reporting path.
• The Python dependency audit in CI is explicitly non-blocking.
• No independent security audit is published.
• Plugins execute as trusted code; plugin CSS can also make network requests. A project can record plugin URLs, so opening third-party projects and installing marketplace plugins expands the supply-chain boundary.
• The current Dockerfile warns that its CSP permits requests to each visitor's localhost and that the image is intended for local or single-user use. Upstream explicitly tells public operators to remove those allowances.
• Docker's optional Basic Auth is not transport encryption. The documentation says to place a TLS-terminating reverse proxy in front of it on untrusted networks.

This does not make GeoLibre unsafe by definition. It means a public or regulated deployment needs its own threat model, image pinning, reverse proxy, TLS, access control, egress restrictions, plugin policy, logging, backups, and patch process.

The lowest-risk starting point is the official desktop installer or the hosted web application with non-sensitive test data. Public self-hosting should come later, after the team has reviewed the Dockerfile and built a hardened deployment profile.

Performance and offline use vary by platform

"Runs locally" and "runs offline" are not identical.

The web app precaches its shell and caches many hashed application assets after first use. Default basemaps and some components can also be cached. However, Pyodide and the PGlite/PostGIS engine load from jsDelivr by default, and many tile, WMS, WFS, ArcGIS, and cloud sources are network-only. Air-gapped deployment requires mirroring or bundling these runtimes and supplying local basemaps and datasets.

The official architecture documentation also records a significant Linux desktop limitation. Tauri uses WebKitGTK there, and upstream measurements found tile-heavy panning falling to single-digit frame rates while tiles loaded. The browser build on Chromium did not show the same behavior. Linux teams should compare the browser, PWA, and desktop builds on representative hardware rather than assuming the native package is faster.

The Docker image is multi-architecture, but its sidecar differs by CPU. freestiler and whitebox-workflows are installed only on amd64 because upstream wheels are unavailable for arm64; client-side WebAssembly tools still work on both.

License, cost, and lock-in

GeoLibre uses the permissive MIT license. The repository's license history shows the current MIT file in place since June 10, and no subscription is required for the software.

The real adoption cost is operational:

• testing file fidelity and CRS behavior;
• maintaining approved versions across desktop, browser, Android, Python, and Docker;
• hosting containers, TLS, authentication, backups, and monitoring;
• paying for optional commercial imagery, geocoding, storage, AI, or cloud data providers if free limits are insufficient;
• training users who expect Google Earth or QGIS behavior;
• retesting projects after rapid releases.

Vendor lock-in is lower than with a proprietary cloud project. GeoLibre projects are JSON, many source formats are open, and projects can be exported as standalone interactive HTML. Portability still depends on the referenced basemaps, external URLs, API keys, plugin availability, and provider terms. A project file is portable only when its dependencies are portable.

Alternatives to evaluate in parallel

QGIS is the most important comparison. Its current release is 4.2.0 from July 3, while 3.44.12 remains the long-term release for teams prioritizing stability. GeoLibre should earn production scope by passing the same datasets and decisions in parallel with QGIS, not by replacing it on the basis of interface convenience.

A practical evaluation plan

1. Inventory the workflow

List the exact KML/KMZ, GeoPackage, shapefile, raster, WMS/WFS, 3D, and database sources in use. Record required coordinate systems, styles, labels, time data, attachments, printing, editing, and export behavior. Separate Google-provided imagery or Street View needs from portable data.

2. Pin the evaluated versions

Record GeoLibre 2.3.0 for desktop and Android, the actual PyPI version for notebooks, and an immutable container tag or digest. Do not evaluate main or an unpinned latest image and later assume the result applies to another build.

3. Build a representative test pack

Use anonymized copies of at least ten projects, including the largest and most unusual files. For each one, compare GeoLibre with the current source application and QGIS:

• feature and layer counts;
• coordinate placement and CRS;
• styles, labels, attachments, and time properties;
• load time and interaction latency;
• edits, saves, reopens, and exports;
• visual differences at predefined checkpoints.

Reject the pilot if any required layer is silently omitted or moved, or if a saved project cannot be reopened in the pinned version.

4. Test privacy and security profiles

Capture outbound requests with optional features disabled, then enable basemaps, geocoding, AI, collaboration, and sharing one at a time. Verify exactly what leaves the device. Open a project containing an external plugin only in a disposable profile and confirm that the trust prompt is understandable.

For Docker, remove the localhost CSP allowances, terminate TLS, configure authentication, restrict egress, mount only a dedicated data directory, disable the sidecar if unnecessary, and scan the final image. Do not expose the upstream default unchanged.

5. Test failure and recovery

Disconnect the network after the app and required runtimes are cached. Confirm which layers and processing engines still work. Restore a saved project on another machine. Test an upgrade and rollback with copied data. On Linux, compare WebKitGTK desktop rendering with Chromium-based PWA performance.

6. Set adoption gates

A reasonable first gate is:

• all required test datasets load with correct counts and CRS;
• no unexpected network request occurs in the restricted profile;
• a fresh machine can restore and reopen every approved project;
• the team can roll back one release without losing source data;
• no critical workflow depends on an unreviewed plugin or a single public service;
• the browser or desktop build meets the team's measured latency target on normal hardware.

If GeoLibre passes, give it one narrow production role—such as internal viewing, training, or portable project sharing—before expanding scope.

Who should adopt it—and who should wait

Good pilot candidates: educators, researchers, civic-data teams, notebook users, and analysts who need a modern cross-platform viewer for open geospatial data. GeoLibre is especially attractive when browser access, local processing, and easy project portability matter more than a mature plugin ecosystem.

Adopt for a narrow role: teams moving away from Google Earth Pro whose workflows center on KML/KMZ, open basemaps, custom layers, simple analysis, and presentations. Keep the original application and QGIS available during migration.

Wait or retain QGIS: regulated organizations, complex editing and topology workflows, large spatial databases, production cartography, air-gapped environments without time to mirror dependencies, and teams that require a formal security-response process or multiple independent maintainers.

GeoLibre is one of the more credible young open-source GIS projects because it combines a useful architecture with current documentation and active maintenance. Its biggest risk is not missing ambition; it is trying to absorb too much surface area too quickly. Treat version 2.3 as a promising pilot platform, prove the exact data and security boundaries, and expand only after the workflow survives repeatable tests.

Sources

Primary sources were accessed on July 29, 2026 unless another date is stated.

• GeoLibre repository and README — OpenGeos; current architecture, platforms, activity, MIT license, and repository status.
• GeoLibre v2.3.0 release notes — OpenGeos; released July 25, 2026; changes and signed release assets.
• GeoLibre releases — OpenGeos; release cadence and version history.
• Getting Started — OpenGeos; web, desktop, Android, Jupyter, Docker, offline, and build guidance.
• GeoLibre architecture — OpenGeos; application components, sidecar, container, offline boundaries, security controls, and Linux WebKitGTK performance.
• GeoLibre privacy policy — OpenGeos; updated June 21, 2026; local processing and optional third-party data flows.
• GeoLibre project guide — OpenGeos; project contents, local save behavior, and public sharing.
• GeoLibre plugin API — OpenGeos; plugin execution, marketplace, CSP, and trust boundary.
• GeoLibre Dockerfile — OpenGeos; container architecture, CPU differences, data confinement, and public-host warning.
• GeoLibre CI workflow — OpenGeos; dependency audits, tests, and the advisory-only Python audit.
• GeoLibre on PyPI — Python Package Index and OpenGeos; current Jupyter package version, requirements, provenance, and release history.
• Update Google Earth Pro — Google; current 7.3.7 installers and the June 25, 2027 download deadline.
• Google Earth plans and capabilities — Google; current web product direction and professional tiers.
• QGIS downloads — QGIS Project; QGIS 4.2.0 and 3.44.12 LTR status as of July 2026.
• QGIS license — QGIS Project; GPL licensing terms.

Discovery and interest signals, not used as sole evidence for technical claims:

• GitHub Trending — GeoLibre appeared among the daily trending repositories on July 29, 2026.
• Reddit discussion of the Google Earth Pro desktop transition — independent GIS-community interest, objections, and alternative discussion.
• Reddit discussion of Google Earth's new professional tiers — independent adoption signal; technical conclusions above rely on primary sources.