Operations and Maintenance

This page covers post-deployment concerns for Okareo Standalone: webhook notifications, secret handling, TLS termination, backups, upgrades, and support.

Webhook notifications

Okareo can post alert messages to Slack and Microsoft Teams using customer-owned Incoming Webhooks. The standalone deployment never holds Okareo-owned credentials. You create webhooks in your own workspace or tenant, then paste the URLs into the Okareo UI under Settings > Notifications.

If you do not need webhook alerts, leave AIRGAP_WEBHOOK_NOTIFICATIONS_ENABLED=false (the default). No egress rules or provider setup are required.

AIRGAP_WEBHOOK_NOTIFICATIONS_ENABLED is an install-wide setting. Which providers an operator connects (Slack, Teams, both, or neither) is a per-project choice made in the UI.

Egress requirements

You only need to allow egress to the hosts you plan to use.

Provider	Host(s)
Slack	hooks.slack.com
Microsoft Teams (legacy O365 Connector)	*.webhook.office.com
Microsoft Teams (Power Automate on Logic Apps)	*.logic.azure.com
Microsoft Teams (Power Automate on Power Platform)	*.api.powerplatform.com

Test reachability from the services container:

docker exec -it okareo_services curl -sSI https://hooks.slack.com/ -o /dev/null -w "%{http_code}\n"

A response in the 2xx, 3xx, or 4xx range confirms the host is reachable. A connection timeout or DNS failure means your firewall or proxy rules need updating.

Enable webhooks

Set the environment variable on the services container and restart:

AIRGAP_WEBHOOK_NOTIFICATIONS_ENABLED=true

After the restart, the Notifications section appears in Settings for each project.

Slack webhook setup

1. Go to https://api.slack.com/apps and click Create New App > From scratch.
2. Name the app (for example, Okareo Alerts) and select your workspace.
3. In the app settings, navigate to Incoming Webhooks and toggle it on.
4. Click Add New Webhook to Workspace and select the channel that should receive alerts.
5. Copy the webhook URL. It starts with https://hooks.slack.com/services/.
6. In the Okareo UI, go to Settings > Notifications, find the Slack card, paste the URL, and click Connect.

Microsoft Teams webhook setup

Two URL families are supported:

Legacy O365 Connector:

1. Open the target channel in Teams.
2. Click More options (...) > Connectors > Incoming Webhook > Configure.
3. Name the connector and click Create.
4. Copy the generated URL.

Power Automate Workflow:

1. Open the target channel in Teams.
2. Click More options (...) > Workflows.
3. Select Post to a channel when a webhook request is received, then save.
4. Copy the workflow URL.

In the Okareo UI, go to Settings > Notifications, find the Microsoft Teams card, paste either URL, and click Connect. Okareo auto-detects the URL family and renders the correct card format.

Verify delivery

After connecting a provider, click the Send test button in the connected card. A test message should appear in the target channel within a few seconds.

Per-tenant configuration

For multi-tenant installs, repeat the Connect step inside each tenant. Webhook configurations are not shared across tenants.

Rotating or disconnecting webhooks

• Rotate: Click Connect again with a new URL. The new URL overwrites the existing one.
• Disconnect: Click Disconnect on the provider card. This removes that provider's credentials only; other connected providers are unaffected.

Webhook URL security

Webhook URLs are treated as secrets. Okareo does not return them in read APIs, does not log them, and does not display them after the initial connect. Do not paste webhook URLs into shared documents or commit them to source control.

Secret handling

Treat the following values as secrets:

• <OKAREO_AIRGAP_TOKEN> (your license token)
• All provider API keys in model.json
• Webhook URLs
• Database credentials

Recommended approaches

Approach	Details
Secrets manager	Use Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager with runtime injection into environment variables.
Docker secrets	Use your orchestration platform's native secret mechanism (Docker Swarm secrets, Kubernetes Secrets).
.env file	Exclude from version control (add to .gitignore) and set restrictive file permissions (chmod 600 .env).

Do not commit secrets to version control. Do not store secrets in plaintext configuration files that are shared or backed up without encryption.

Rotate credentials according to your organizational policy and audit access to secret stores regularly.

TLS and reverse proxy (Docker path)

For team usage, terminate TLS with a reverse proxy (NGINX, Traefik, HAProxy, or a cloud load balancer) in front of the Okareo containers. Then update your environment:

OKAREO_APP_DOMAIN=https://<UI_HOST>
OKAREO_API_GATEWAY=https://<API_HOST>

Keep internal service ports private. Only expose the UI and API ports through the reverse proxy. Do not expose Postgres, Redis, or NATS ports externally.

For Kubernetes TLS termination, see Configure HTTPS / TLS Termination.

Self-signed certificates for custom HTTP targets

If your model endpoints or custom HTTP targets use certificates signed by an internal CA, the services container must trust that CA.

Option A (recommended): Mount the internal CA into the container.

Extract the container's default CA bundle and append your CA certificate:

docker run --rm okareoartifacts/appservices:<version> cat /etc/ssl/certs/ca-certificates.crt \
  | sudo tee /opt/okareo/ca-bundle.pem > /dev/null
sudo tee -a /opt/okareo/ca-bundle.pem < your-ca.pem

Add these environment variables to the services container:

REQUESTS_CA_BUNDLE=/etc/ssl/certs/okareo-ca-bundle.pem
SSL_CERT_FILE=/etc/ssl/certs/okareo-ca-bundle.pem

Add a volume mount so the container can read the bundle:

-v /opt/okareo/ca-bundle.pem:/etc/ssl/certs/okareo-ca-bundle.pem:ro

Option B: Disable TLS verification for custom endpoints.

If mounting the CA is impractical, set:

OKAREO_CUSTOM_ENDPOINT_SSL_VERIFY=false

This disables TLS certificate validation for Custom HTTP Endpoint targets only. All other TLS connections (database, Redis, external APIs) are unaffected.

Backups for Postgres

For production deployments, use an external managed Postgres instance with automated backups, or ensure the Docker volume backing Postgres is on durable storage.

At minimum, schedule regular pg_dump backups:

docker exec -t okareo_db pg_dump -U postgres okareo_db > okareo_db_backup.sql

Store backups in a location separate from the host running Okareo. Test restores periodically to verify backup integrity.

Upgrades

Follow this sequence to upgrade Okareo Standalone safely:

1. Back up Postgres and critical configuration files (especially model.json).
2. Load or pull new images. For air-gapped environments, use docker load. Otherwise, pull from Docker Hub with the new version tag.
3. Stop and recreate containers with the new image tags. Use the same environment variables and volume mounts.
4. Verify the deployment. Check /v0/health on the API and run smoke tests against the UI.

Always read the release notes for the target version. Some releases may include database migrations or require new environment variables.

Support

Getting started after deployment

After a successful deployment:

1. Open the UI at your configured OKAREO_APP_DOMAIN URL.
2. Confirm that model providers appear (configured via model.json).
3. Register a model under test.
4. Run a first evaluation or simulation workflow.

Contacting support

When reaching out to Okareo support, provide:

• Redacted configuration: Your environment variables with tokens and keys replaced by placeholders.
• Redacted model.json: The model configuration file with API keys and tokens removed.
• Container logs: Output from the services, frontend, and database containers. Collect with docker logs <container_name>.

Environment variable reference

Variable	Description	Required	Default
AIRGAP_WEBHOOK_NOTIFICATIONS_ENABLED	Enable the webhook notification UI in Settings	No	false
OKAREO_CUSTOM_ENDPOINT_SSL_VERIFY	Verify TLS certificates for custom HTTP targets	No	true
REQUESTS_CA_BUNDLE	Path to a custom CA bundle inside the container	No	—
SSL_CERT_FILE	Path to the SSL certificate file inside the container	No	—
SSO_COOKIE_DOMAIN	Override the cookie domain for split-subdomain deployments	No	(auto-inferred)
STDOUT_LOG_LEVEL	Console log level (10=DEBUG, 20=INFO, 30=WARNING, 40=ERROR, 50=CRITICAL)	No	30
FILE_LOG_LEVEL	File log level	No	30
TRACE_THREAD_POOL_SIZE	Thread pool size for trace processing	No	4
TASK_LISTENER_ENABLED	Enable the async task listener	No	true
DISABLE_TELEMETRY	Disable internal telemetry	No	TRUE

---

Related: Deploy with Docker | Deploy on Kubernetes | Model Configuration