Skip to content

Getting started (end users)

This guide aims to get you from “I’ve never used Sites” to “I have a working site and can publish content”.

Step 1 — Sign in to the Hub

  1. Open the Sites Hub in your browser.
  2. Sign in with your ECMWF account (OpenID Connect).

If you can’t sign in, see 10-troubleshooting.md.

Step 2 — Create a site

On the Hub home page, choose Create a site.

You’ll usually provide:

  • Space: your team/project grouping (part of the URL); if you leave it empty, the owner’s username is used
  • Name: short name used in the URL
  • Description (optional)
  • Type: private or public
  • Retention Date: the site is scheduled to expire on this date — it is first archived and later deleted. The form pre-fills one year ahead; refresh the date as long as the site should live.
  • Site Template (optional): when the deployment provides templates, picking one pre-fills the form; anything you enter yourself wins. See Site settings.

Choosing private vs public

  • Choose private if the content is internal or not ready.
  • Choose public only when you intend the content to be readable by anyone with the link.

The type is locked for normal users: switching a site between private and public requires a Hub administrator (ask through the usual support channel). It’s easier to start private.

Step 3 — Confirm sharing and admin rights

After creation, open your site in the Hub:

  • add who should be able to view (users/groups) — if you leave both viewer fields empty, the platform’s default viewer group is used, which normally covers all ECMWF staff
  • add who should be able to administer the site (admins) — you are an administrator automatically as the owner, so this is where you add other maintainers

Forgetting to add the second group of people is the most common mistake: when the owner is away, nobody can change the site.

See 03-managing-access.md.

Step 4 — Find your site URL

In the Hub site view, you’ll find the site’s URL.

The usual pattern is:

  • https://<domain>/<space>/<site>/

Browsing a site

Opening the site URL shows a file listing (unless the site publishes its own index.html). The listing has:

  • A search box: filters the entries on the current page by name, case-insensitive; it works in both layouts and never reloads the page.
  • Sort controls: Date, Name, or Size, ascending or descending. Sorting reloads the listing from the server and the order is part of the URL (?C=…;O=…), so a sorted view can be shared.
  • List and grid layouts: the grid shows image thumbnails where available.
  • Download folder: zips the current folder on the spot.

Site administrators see more in the browser: Edit Mode (Ctrl+E) adds delete buttons, a folder-creation dialog, and a drag-and-drop upload area; right-click a file to create signed or session links (see Signed and session URLs). A banner appears on sites whose retention date has passed.

Step 5 — Publish something

You have multiple choices. The best one depends on what you’re doing:

  • Use the Sites CLI for command-line workflows or the Sites SDK for Python integrations.
  • Use the Site API directly when you need to make HTTP requests yourself.
  • If your site has WebDAV or S3 enabled: you can use those interfaces.

Start with the general overview:

Or jump directly to a practical API cookbook:

Each site provides a health endpoint:

  • GET https://<domain>/<space>/<site>/s/api/v2/health/

This endpoint is guarded like the rest of the Site API: it works in your browser when you are signed in as a site administrator, and needs a Site API token when called from a script. If your site behaves oddly (uploads fail, pages don’t load), it is a quick first check.