Built-in Site applications¶

This page collects the built-in applications of a Site Pod. The registry and shared container rules are in site application architecture. Each application also has its own page:

• site initializer
• site OAuth2
• site proxy
• site API
• site admin
• site WebDAV
• site S3

Application sets and selection¶

The platform splits the applications into three sets: the registry keeps init applications apart from normal containers (core/.../model/site_apps_registry.py); the basic and essential sets are computed by SiteApplicationsBuilder (core/.../model/site.py) from the site_apps flags in each app_config.py.

• Init applications: run before the normal containers. Only site-initializer is in this set.
• Essential applications: site-initializer, site-oauth2, site-api, site-proxy. SiteConfiguration.set_applications re-adds them on every change, so a Site cannot remove them (12).
• Basic applications: the default list for a new Site: the four essential applications plus site-admin.

A normal application creates a container only when the Site specification lists it with an image (image_available()). A specification entry without an image does not select the application; adding an image for site-webdav or site-s3 enables that container.

The Site form's applications field processes selections in order (SiteApplicationsBuilder.from_form, core/.../model/site.py):

• A name that starts with - removes that application from the default list (for example -site-admin). The - syntax is processed only on create; on update the service resolves every token verbatim and rejects - names.
• site-admin is the only default application that this syntax can remove; the essential set is restored afterwards.
• Unknown names are skipped on create; on update the service raises Application <name> not supported!.
• site-custom is added when the form carries a custom image (custom applications).

When site-admin is removed: the container is absent, the admin-logo.svg and admin-favicon.svg keys disappear from the files ConfigMap, and the proxy does not render the admin location — the path falls through to the default file-listing rule (site proxy).

Container and Service behaviour¶

Only selected optional applications are added to the container list. The Site Service exposes exactly one port — site-oauth2 on 4180 — and site-oauth2 owns the route for the Site path; other applications and optional applications do not create independent Service ports, Ingress, or HTTPRoute objects (SiteExporter.to_service, get_service_ports()). The Service uses sessionAffinity: ClientIP with a 10800-second timeout, so one client keeps its sticky session, which the OAuth2 session cookie needs.

Resource tiers¶

Each application module defines its own RESOURCE_LIMIT table (<application>/app_config.py). All current modules override the base table (domain model). The Site setting settings.resource_limits selects one tier per Site, and the same tier applies to every container. The tables below give the memory and CPU request and limit of each built-in application per tier. A limit of no limit means the code sets MAX: None, which leaves the corresponding Kubernetes limit unset, so the container can burst without a bound.

Memory (request / limit):

CPU (request / limit):

The initializer takes the same values in every tier. The custom application and the content mirror define their own tables (custom applications, content mirror).

Build metadata¶

Every Site image records its build at image-build time with the mandatory TAG build argument and the IMAGE_TAG environment variable. Seven of the eight images also write a /etc/build-date file; api.Dockerfile does not, because its final stage is distroless. Only the initializer and the mirror print a version banner; the proxy and OAuth2 entrypoints export BUILD_DATE from /etc/build-date without printing. The Go API serves IMAGE_TAG at /api/v2/version/ (see 07-site-api).