The THREDDS Data Server publishes scientific data collections over OPeNDAP, DAP4, OGC WMS and WCS and the NetCDF Subset Service, serving sample data from first boot.
The THREDDS Data Server is the reference server from NSF Unidata for publishing scientific data. Point it at a directory of netCDF, HDF, GRIB or NEXRAD files and it exposes every one of them through the remote access protocols the earth science community already uses: OPeNDAP and DAP4 for programmatic subsetting from Python, R, MATLAB, Panoply or the netCDF C library, OGC WMS for map layers a GIS client can consume, OGC WCS for coverage retrieval, the NetCDF Subset Service for pulling a bounding box or a time range straight out of a large grid, and plain HTTP for whole file download.
What ties it together is the THREDDS catalog, an XML description of the data holdings that clients crawl to discover what is available and how to reach it. Catalogs can be written by hand for curated collections, or generated automatically by scanning a directory, and the server can aggregate many files into a single logical dataset so a whole model run series appears to a client as one continuous time axis. It is the software behind a large share of the world's public meteorology, oceanography and climate data nodes, and it is typically deployed as one dedicated data node in front of a storage volume.
cloudimg delivers the THREDDS Data Server as a complete appliance with the servlet container, the Java runtime and a hardened reverse proxy already installed and tuned, and with a working catalog of sample datasets in place, so a browser and an OPeNDAP client both get real data back as soon as first boot finishes. Security is the reason to take this image rather than assemble it yourself. The data services are public because that is what a data server is for, but the remote management surface is not: it is reachable only over TLS and only to an administrator account whose password is generated uniquely on each instance at first boot and written to a root only file, and it is refused outright over plain HTTP so those credentials never cross the network in the clear. The image contains no account and no private key at all before first boot runs, the servlet container ships with no users, no roles and no management applications, and the container itself listens only on the loopback interface behind a reverse proxy that forwards an explicit allowlist of paths and answers everything else with a not found. The server is also configured never to fetch a caller supplied URL and never to make an unsolicited outbound call, so it runs correctly with no internet access. The base is fully patched with unattended security upgrades enabled, the heap is sized from the actual memory of whatever instance size you launch, and every deployment is paired with a step by step deploy guide and backed by 24/7 cloudimg support.
Real screenshots taken while testing this image against its deployment guide.