The rapid growth in Earth observation (EO) and Digital Twin Earth data volumes creates a need for global, reproducible, and cloudnative spatial representations. Conventional latitude–longitude grids and projected tiling systems remain useful, but they introduce projection boundaries, non-uniform cell areas, and repeated reprojection costs when combining multi-source products. Grid4Earth addresses this problem through an open-source Python ecosystem built around an ellipsoidal HEALPix Discrete Global Grid System (DGGS) representation and Zarr-based data handling. The ecosystem consists of four composable packages: <code>healpix-geo</code> for WGS84-aware indexing and coverage queries, <code>healpix-resample</code> for CPU/GPU-capable regridding, <code>healpix-plot</code> for visualisation, and <code>healpix-analyse</code> for diagnostics and analysis. We situate Grid4Earth in relation to previous DGGS comparisons, XDGGS, and OGC API – DGGS work, focusing on the implementation layer required for EO workflows. When WGS84 geodetic latitude is passed directly to spherical HEALPix, local cell areas vary by up to approximately 0.9% because of Earth’s non-spherical shape. Grid4Earth preserves the HEALPix equal-area property on WGS84 through an authalic-latitude mapping. The ecosystem has been exercised in HEALPix/Zarr workflows for Sentinel-2, Sentinel-3, ERA5, CAMS, and DestinE Climate Digital Twin outputs. This paper describes the ellipsoidal geometry, the CPU/GPU-capable resampling architecture, and the implementation of metadata fields defined by CF 1.13 and version 1 of the Pilot Zarr DGGS convention, establishing ellipsoidal HEALPix/Zarr as a common representation that connects climate and Digital Twin Earth datasets with ellipsoidal EO datasets.