Installation

There are two prepared ways to install Nova. Both build the image from deploy/Dockerfile and run Nova together with PostgreSQL 16. The templates are in the deploy/ directory; the commands below run in the directory that contains deploy/. What has to be in place beforehand is described in Requirements.

Single server with Docker Compose

The template deploy/docker-compose.yml starts Nova and PostgreSQL as containers. The database lives in a Docker volume of its own and survives restarts and updates.

1. Create the configuration. Copy deploy/.env.example to deploy/.env and set at least SECRET_KEY, NOVA_ENCRYPTION_KEY and a dedicated DB_PASSWORD; RUN_DUMMIES stays at 0. The two keys can be generated as follows, the second one with Python and the cryptography package:

   openssl rand -hex 32
   python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"

2. Prepare for the TLS proxy. In deploy/.env, set APP_BIND=127.0.0.1 so that Nova can only be reached from the server itself, plus TRUST_PROXY=1 and SESSION_COOKIE_SECURE=1.
3. Build and start.

   docker compose -f deploy/docker-compose.yml --env-file deploy/.env up -d --build app
   docker compose -f deploy/docker-compose.yml --env-file deploy/.env logs -f app

   The first run builds the image and takes a few minutes. Nova is ready as soon as the log shows Gunicorn listening on port 8000. The template also contains the handbook service, which serves this handbook; Nova does not need it.
4. Set up the TLS proxy. A web server on the host accepts HTTPS and forwards to http://127.0.0.1:8000. The nginx templates in deploy/nginx/ show the settings: pass on the headers Host, X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host, allow uploads of up to 25 MB and set timeouts of 120 seconds. The certificate can be obtained from Let's Encrypt with certbot, for example.

Do not run without TLS

Without an upstream proxy, Nova serves plain, unencrypted HTTP only. Put a TLS proxy in front of it before using it with real data.

SAP BTP, Kyma runtime

The templates in deploy/kyma/ run Nova in a Kyma cluster: a Deployment for Nova, PostgreSQL as a StatefulSet with its own volume, and an APIRule that makes Nova reachable over HTTPS through the Kyma gateway – at https://nova-iam.‹cluster domain›.

1. Access and namespace. Set up kubectl with the cluster's kubeconfig; sign-in runs through the OIDC plugin kubelogin. Create a namespace, for example nova-iam. If the image is in a private registry, also create an image pull secret.
2. Provide the image. Build the image from deploy/Dockerfile, push it to the registry and enter it in deployment.yaml. Give every new version a new tag: a node does not pull a tag it has already pulled.
3. Create the secret. Nova and PostgreSQL read their environment from the secret nova-secrets, template secret.example.yaml: POSTGRES_DB, POSTGRES_USER, POSTGRES_PASSWORD, DB_NAME, DB_USER, DB_PASSWORD (same as POSTGRES_PASSWORD), SECRET_KEY and NOVA_ENCRYPTION_KEY. Further variables such as SESSION_COOKIE_SECURE=1 or NOVA_SMTP_* are added as extra keys. The real values do not belong in version-controlled files.
4. Adapt for production. The template is designed for a demo: in deployment.yaml, set RUN_DUMMIES to "0" and do not apply dummies-expose.yaml. Keep replicas: 1 and the Recreate strategy – this way two instances never run at the same time.
5. Apply.

   kubectl -n nova-iam apply -f deploy/kyma/postgres.yaml
   kubectl -n nova-iam apply -f deploy/kyma/deployment.yaml
   kubectl -n nova-iam apply -f deploy/kyma/apirule.yaml
   kubectl -n nova-iam rollout status deploy/nova-iam

The first start

On start, Nova creates the database schema and brings it up to date on every subsequent start. On the first start, Nova also writes basic data, including:

• an administrator account with a preset password, which administrators should change right after the first sign-in,
• the entitlements “Admin”, “Manager”, “Security” and “SoD Reviewer”,
• the preset background jobs, see Monitoring and jobs,
• two example target systems pointing to local test services: “SCIM Dummy Target” and “LDAP Directory”.

Administrators then connect their own target systems under “Systems”, see Target systems – Overview. How updates and backups work is described in Updates and backup.