ERDDAP on Google Cloud

A practical deployment guide based on the SWFSC implementation

This book is a practical guide for deploying and maintaining ERDDAP on Google Cloud Platform (GCP). It is based on the architecture and deployment experience of the NOAA CoastWatch West Coast Node at SWFSC, but the core setup path is written for other groups building their own ERDDAP environment.

The guide complements the official ERDDAP installation documentation. It focuses on the surrounding cloud infrastructure: Compute Engine, persistent storage, optional Google Cloud Storage access, Identity-Aware Proxy, load balancing, Terraform, service management, validation, backup, and recovery.

Who this guide is for

The primary audience is a technical team responsible for deploying or administering ERDDAP in a NOAA or similar managed GCP environment. Readers should be comfortable with Linux administration, the command line, GCP resources, and basic Terraform workflows.

Before beginning, identify who owns:

  • the GCP project, billing, quotas, and organization policies;
  • IAM roles and service accounts;
  • the VPC, subnet, firewall rules, and proxy-only subnet;
  • the HTTPS load balancer, certificate, DNS, and external routing;
  • Terraform source and state;
  • ERDDAP configuration, datasets, and ongoing operations.

These responsibilities may be split across the ERDDAP team, a platform team, and organizational IT. The guide identifies the required components but cannot grant permissions or create resources controlled by another team.

What the guide covers

The core deployment path covers:

  1. selecting an ERDDAP architecture and sizing approach;
  2. provisioning VMs, disks, buckets, IAM, and snapshot policies;
  3. connecting to private VMs through Identity-Aware Proxy;
  4. safely initializing persistent storage;
  5. optionally mounting a GCS data bucket through rclone;
  6. installing pinned Java, Tomcat, and ERDDAP versions;
  7. validating ERDDAP locally before connecting it to a load balancer;
  8. verifying private, load-balanced, and public access;
  9. preparing the system for production use, backup, reboot, and recovery.

What the guide does not prescribe

Every group has different datasets and processing responsibilities. The core guide does not prescribe:

  • how source datasets are acquired or copied;
  • how an on-premises ERDDAP is synchronized during migration;
  • how individual datasets.xml definitions are authored;
  • a specific scientific-processing workflow;
  • SWFSC dataset inventories, migration waves, or internal tracking procedures.

Those activities belong in dataset-specific repositories, internal runbooks, or project-management systems.

Reference architecture

The required serving environment is deliberately small:

  • a private Compute Engine VM running Tomcat and ERDDAP;
  • a persistent disk for ERDDAP working files, logs, and cache;
  • an HTTPS load balancer and health check for public access;
  • Terraform or another reviewed infrastructure-as-code process.

A GCS data bucket and rclone mount are optional. They are useful for large file-backed datasets, but an ERDDAP that serves remote HTTP, THREDDS, or other ERDDAP sources may not need them.

Processing VMs, Cloud Run Jobs, Cloud Scheduler, Artifact Registry, and Secret Manager are also optional. They support data-generation workflows but are not prerequisites for running ERDDAP.

See Project Architecture for the complete design and decision points.

Book organization

Deploy ERDDAP on GCP

These chapters form the reusable deployment path:

Optional processing infrastructure

These chapters apply only when the group also operates data-processing systems:

SWFSC implementation examples

The workflow and source-code sections document pipelines developed during the SWFSC migration. They are examples of how one group organized cloud processing; they are not required steps in an ERDDAP deployment.

Validated baseline

The ERDDAP VM procedure was validated on a new Ubuntu 22.04 VM with a persistent data disk, an optional read-only rclone mount, Temurin Java 25.0.1+8, Tomcat 11.0.26, and ERDDAP 2.31.1. The repository installation script pins the versions it installs. Review and retest those pins before upgrading any component.

This documentation remains a living reference. Infrastructure examples must be adapted to the target project, security policy, workload, and ownership model before they are applied.