Skip to main content

Installation

This page shows a simple, repeatable path to get SafariDesk running on a single host using Docker Compose.

Full customer journey (from zero to usable)

Use this sequence for enterprise self-hosted onboarding:
  1. Prepare host machine (Docker + Compose, networking, DNS)
  2. Clone SafariDesk and create .env
  3. Configure core settings (DB_*, REDIS_*, SUPERUSER_*, URLs)
  4. Configure enterprise licensing values provided by SafariDesk
  5. Start the stack with Docker Compose
  6. Validate services, run first login, and confirm license status
  7. Configure email, optional AI, backups, and monitoring
When these steps are complete, the system is ready for daily ticketing use.

Preflight (do this first)

  • Install Docker and Docker Compose on your host
  • Make sure you run commands from the Core/ directory (the Docker Compose file lives there)
  • Confirm you have 4+ GB RAM available

Operating system options

SafariDesk is Docker Compose-based and is not strictly Ubuntu-only.
  • Production recommendation: Linux host (Ubuntu 22.04+ recommended)
  • Also possible: Debian/RHEL-family Linux, macOS, and Windows with Docker Desktop

Ubuntu / Debian (example)

RHEL / Rocky / AlmaLinux (example)

macOS (example)

Windows (example)

For production workloads, prefer Linux because Docker Desktop on macOS/Windows is VM-based.

1. Clone the repository

Linux/macOS (bash):
Windows (PowerShell):

2. Create and edit the environment file

Linux/macOS (bash):
Windows (PowerShell):
Minimum values to set before first start:
  • SECRET_KEY — a random Django secret
  • DB_PASSWORD — Postgres password used by the db container
  • SUPERUSER_USERNAME, SUPERUSER_PASSWORD, SUPERUSER_EMAIL
  • SMTP values (if you want email functionality)
  • Enterprise license values from SafariDesk (see Configuration)
See Configuration for a full list of variables and examples.

3. Start the stack

Run from Core/: This command is the same in Linux/macOS and Windows PowerShell.
The first run builds images and initializes the database — expect a few minutes.

4. Verify the deployment

Check container health and logs: This command is the same in Linux/macOS and Windows PowerShell.
To run migrations and collect static files (safe to run after first start): This command is the same in Linux/macOS and Windows PowerShell.
When containers are healthy, open the frontend URL (see FRONTEND_URL in .env) and sign in with the SUPERUSER_* account.

5. Activate and verify enterprise licensing (updated UI)

The License UI is in the user Profile page and is an admin-only tab. Follow these steps after you sign in as an administrator.
  1. Sign in as the admin user (created from SUPERUSER_* in .env).
  2. Open your Profile page: http://<frontend-host>/profile (or click the Profile link in the header).
  3. Select the License tab (next to Security). This page shows current license Status, Edition, Features, and Last validated.
  4. Paste the enterprise license key into the License Key field and click Activate.
    • The frontend posts to POST /api/v1/license/activate/ and the backend validates the key with the license-proxy (configured via LICENSE_PROXY_URL in Core/.env).
    • Activation requires a staff/admin account and a valid JWT access token; the frontend includes the token automatically when logged-in.
  5. On success you will see license metadata (customer, edition, features) and enterprise features will be unlocked.
Behavior notes
  • Admin-only: only staff users may activate or revalidate a license. Non-admin requests will receive an authorization error.
  • Offline handling: if the API cannot reach the license-proxy the UI will display cached status and an “offline validation” notice; features remain available until revalidation fails.
  • Security: license payloads are HMAC-signed by the proxy; the backend verifies signatures and stores license data encrypted when LICENSE_ENCRYPTION_KEY is set.
How to test the License UI (beginner-friendly)
  • Confirm the frontend is pointing to the running API: check Core/.env VITE_API_URL (should be http://localhost:9100/api/v1 for local setups). Rebuild the frontend if you change it.
  • From the admin browser session: open DevTools → Network, click Activate, and verify the POST /license/activate/ request returns HTTP 200 and JSON with license details.
  • If you see CORS errors in the browser console (e.g. “No ‘Access-Control-Allow-Origin’ header”), add your frontend origin to CORS_ALLOWED_ORIGINS in Core/backend/RNSafarideskBack/settings/base.py, then restart the API.
  • If activation fails with 4xx, capture the response JSON (it contains a helpful detail field). If the API returns 500, tail the API logs:
Look for a traceback or signature/connection errors. Common fixes: ensure LICENSE_PROXY_URL is reachable (start the local license-proxy service) and LICENSE_RESPONSE_SIGNING_SECRET matches the proxy if you’re running a private proxy. Quick curl examples (use a logged-in admin token if required):
When activation is successful, perform a quick smoke test of an enterprise feature (for example, verify the admin-only report page or integration settings appear). If a feature is missing after activation, restart the frontend to ensure the SPA loaded the latest runtime configuration.

Quick recovery tips

  • If the API is failing, docker compose logs api shows the error
  • If Postgres is not ready, wait and retry migrate
  • If a container fails to build, check the build output and rerun docker compose up -d --build
If you need help, see Troubleshooting.