How to install Open-Meteo on a VPS

Prerequisites

Open-Meteo self-hosting requires significant hardware: 8 GB RAM minimum, 16 GB recommended, a modern CPU with AVX2 support, and at least 150 GB of NVMe SSD storage for comprehensive forecast datasets. A limited single-model setup may fit in 32-48 GB. This is NOT suitable for cheap entry-level VPS tiers.

Heads-up: For most developers, the hosted API (api.open-meteo.com) is free, requires no API key, and is simpler to use. Self-hosting is recommended only for data sovereignty, air-gapped environments, or custom model processing.

Plan for large downloads, model refreshes, cache storage and a public API rate policy. Keep enough disk for a previous model set so that an update can be rolled back. If you only need weather data for an application, consider the hosted endpoint instead.

Step 1, Connecting to your server

Update the host and create separate directories for the API, models and cache:

ssh root@SERVER_IP
apt update && apt upgrade -y
apt install -y ca-certificates curl git
mkdir -p /opt/open-meteo/{app,models,cache,backups}
cd /opt/open-meteo
chmod 750 /opt/open-meteo

Use a disk volume that survives container recreation. Do not put model data on a small system partition. Restrict SSH and keep the model files outside the public web root.

Step 2, Installing Docker and Docker Compose

Install Docker Engine and the Compose plugin using Docker's official Ubuntu instructions:

docker --version
docker compose version
systemctl enable --now docker
df -h
free -h

The official Open-Meteo installation may instead require native tools or a specific runtime. Follow that requirement when the model build does not support Docker.

Step 3, Running the official Open-Meteo build

Download the current source, model assets and build instructions from the official Open-Meteo project. Do not invent a Docker image or use a random weather-model mirror. The required data sources and model versions are part of the product's correctness.

If the selected release provides a container image, put its verified name in .env:

OPEN_METEO_IMAGE=REPLACE_WITH_THE_CURRENT_OFFICIAL_IMAGE
MODEL_DATA_PATH=/opt/open-meteo/models
CACHE_PATH=/opt/open-meteo/cache

A deployment wrapper can look like this:

services:
  api:
    image: ${OPEN_METEO_IMAGE}
    restart: unless-stopped
    environment:
      MODEL_DATA_PATH: /models
      CACHE_PATH: /cache
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - /opt/open-meteo/models:/models
      - /opt/open-meteo/cache:/cache

Use the actual ports, variables, health checks and model mount paths from the official release. Validate it only after replacing placeholders:

docker compose config
docker compose pull
docker compose up -d
docker compose ps

Download weather data immediately. Without this step the API returns empty results:

docker exec -it <container> sync ecmwf_ifs025 temperature_2m

Replace <container> with your actual container name. Record the model version and source dates so that forecasts are reproducible.

Weather model data must be refreshed regularly. Set up a cron job or systemd timer to run the sync command periodically (e.g., every 6 hours):

crontab -e
# Add: 0 */6 * * * docker exec <container> sync ecmwf_ifs025 temperature_2m

Step 4, Configuring the reverse proxy

Route weather.example.com to the API's private localhost port through Nginx or Caddy. Terminate HTTPS, set appropriate body size limits and add caching headers. Example Nginx config:

server {
    listen 443 ssl;
    server_name weather.example.com;

    client_max_body_size 1m;
    proxy_buffering off;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_cache openmeteo;
        proxy_cache_valid 200 30s;
        proxy_cache_use_stale error timeout updating;
    }
}

Keep model storage and administrative endpoints private. Test a health endpoint, a small forecast request and a request that exercises cached data. Do not expose an unbounded model-download or debugging endpoint.

Step 5, First access and initial setup

Open the HTTPS API endpoint and send a small request using the parameters supported by the deployed model set. Verify timezone, coordinates, units and model metadata. Compare a sample response against the official reference before integrating it into a product.

Add monitoring for stale model data. An API can return HTTP 200 while serving outdated or incomplete forecasts, so health checks must include data freshness.

Maintenance

Schedule model refreshes separately from application upgrades. Download new data into a staging directory, validate it and switch atomically when the official process permits. Keep the previous model set for rollback and back up only configuration and metadata when the data is too large for ordinary backups.

Implement cleanup cron jobs — delete compressed files older than 10 days, surface files older than 90 days. Monitor disk usage, as weather data grows continuously.

Monitor disk, CPU, model freshness, API latency and error rate. If the workload exceeds the VPS, move model processing to dedicated compute or use the hosted service rather than disabling validation.