azuretechllc/suitecrm repository overview

⁠AzureTechLLC SuiteCRM Docker Image

Docker deployment and configuration reference for azuretechllc/suitecrm.

This page intentionally focuses on using and deploying the Docker images. Project development, CI, source architecture, and engineering governance belong in the GitHub repository documentation.

⁠Image tags

Production exact-version images:

azuretechllc/suitecrm:<version>

Development exact-version images:

azuretechllc/suitecrm:<version>-dev

Examples:

azuretechllc/suitecrm:8.0.0
azuretechllc/suitecrm:8.0.0-dev

Supported releases target both linux/amd64 and linux/arm64.

Use an exact version tag for controlled deployments. Floating tags are published only according to project release/promotion policy.

⁠What the image provides

The image contains Apache, PHP, the exact SuiteCRM installable application, required PHP modules, approved optional runtime capabilities, Supervisor, lifecycle scripts, health checks, persistence support, database client/backup tooling, cron support, and release-specific worker support where applicable.

The primary SuiteCRM image does not contain MySQL or MariaDB server. Deploy a supported database separately.

The production image excludes development-only Node/npm/Yarn/Angular/Composer/Xdebug tooling. The -dev image adds release-compatible development tooling.

⁠Persistent storage

Mount persistent SuiteCRM state at:

/var/lib/suitecrm

Example named volume:

volumes:
  suitecrm_data:

services:
  suitecrm:
    image: azuretechllc/suitecrm:8.0.0
    volumes:
      - suitecrm_data:/var/lib/suitecrm

Do not treat the container filesystem itself as the durable application state.

Backups created by the image are stored below:

/var/lib/suitecrm/backups/<version>/<timestamp>/

⁠Database requirements

SuiteCRM uses an external MySQL or MariaDB database compatible with the exact SuiteCRM release.

The public deployment variables are:

When using the repository's protected Compose definitions, these values are mapped to the container's internal database connection names.

The database account is required during normal runtime. Changing database environment values does not authorize automatic migration, initialization, or deletion of an existing database.

⁠Fresh-install configuration

These variables initialize a new SuiteCRM installation.

These are install-time settings. After successful installation, changing them does not automatically rewrite the existing SuiteCRM application's administrator account or configuration.

⁠SMTP configuration

SMTP settings may be supplied for fresh installation:

SMTP variables are installation inputs. After installation, SuiteCRM's persisted Email Settings are authoritative; environment drift does not continuously overwrite administrator changes.

⁠PHP runtime configuration

These settings are runtime-mutable and may be changed when recreating an existing container without reinstalling SuiteCRM:

Changing an approved PHP runtime value updates project-owned PHP runtime configuration only. It does not trigger installation, upgrade, downgrade, backup, recovery, or database initialization.

⁠Cron

Cron behavior is lifecycle/release aware.

⁠Worker controls

A worker is started only where the exact SuiteCRM release/runtime supports the applicable worker mechanism.

⁠Development image / Xdebug

The -dev image supports:

Xdebug is not part of the production image.

⁠Deployment variables

The repository's Compose examples also use deployment-side variables:

Publishing a host HTTPS port does not by itself configure certificates or create a TLS listener inside the SuiteCRM container. TLS may be terminated by a reverse proxy.

⁠Docker Compose: external database

Use this topology when MySQL/MariaDB is already deployed elsewhere:

services:
  suitecrm:
    image: azuretechllc/suitecrm:8.0.0
    restart: unless-stopped
    ports:
      - "8080:80"
    environment:
      SUITECRM_HOST: database.example.internal
      SUITECRM_PORT: "3306"
      SUITECRM_DATABASE: suitecrm
      SUITECRM_USER: suitecrm
      SUITECRM_DB_PASSWORD: change-me
      SUITECRM_USERNAME: suitecrm
      SUITECRM_PASSWORD: change-me
      SUITECRM_EMAIL: [email protected]
      SUITECRM_SITE_URL: https://crm.example.com
      SUITECRM_ENABLE_HTTPS: "yes"
      SUITECRM_DEMO_DATA: "no"
      SUITECRM_IGNORE_SYSTEM_CHECK_WARNINGS: "false"
      SUITECRM_VALIDATE_USER_IP: "FALSE"
      PHP_MEMORY_LIMIT: 512M
      PHP_UPLOAD_MAX_FILESIZE: 100M
      PHP_POST_MAX_SIZE: 110M
      PHP_MAX_EXECUTION_TIME: "300"
      TZ: America/Chicago
      SUITECRM_CRON_ENABLED: "yes"
      SUITECRM_CRON_INTERVAL: "60"
      SUITECRM_WORKER_ENABLED: "yes"
    volumes:
      - suitecrm_data:/var/lib/suitecrm

volumes:
  suitecrm_data:

The repository's protected Compose files use the public DB_* deployment contract and map it into the SuiteCRM container. The direct-container example above shows the current internal names because it bypasses that Compose mapping.

⁠Docker Compose: SuiteCRM with MariaDB

A database service may be deployed separately in the same Compose project:

services:
  database:
    image: mariadb:10.6
    restart: unless-stopped
    environment:
      MYSQL_ROOT_PASSWORD: change-root-password
      MYSQL_DATABASE: suitecrm
      MYSQL_USER: suitecrm
      MYSQL_PASSWORD: change-db-password
    volumes:
      - database_data:/var/lib/mysql

  suitecrm:
    image: azuretechllc/suitecrm:8.0.0
    restart: unless-stopped
    depends_on:
      - database
    ports:
      - "8080:80"
    environment:
      SUITECRM_HOST: database
      SUITECRM_PORT: "3306"
      SUITECRM_DATABASE: suitecrm
      SUITECRM_USER: suitecrm
      SUITECRM_DB_PASSWORD: change-db-password
      SUITECRM_USERNAME: suitecrm
      SUITECRM_PASSWORD: change-admin-password
      SUITECRM_EMAIL: [email protected]
      SUITECRM_SITE_URL: https://crm.example.com
      SUITECRM_ENABLE_HTTPS: "yes"
      SUITECRM_DEMO_DATA: "no"
      PHP_MEMORY_LIMIT: 512M
      PHP_UPLOAD_MAX_FILESIZE: 100M
      PHP_POST_MAX_SIZE: 110M
      PHP_MAX_EXECUTION_TIME: "300"
      TZ: America/Chicago
      SUITECRM_CRON_ENABLED: "yes"
      SUITECRM_WORKER_ENABLED: "yes"
    volumes:
      - suitecrm_data:/var/lib/suitecrm

volumes:
  suitecrm_data:
  database_data:

For production, replace every example credential and URL. Do not use example/default passwords as production secrets.

⁠Docker run

With an existing database:

docker volume create suitecrm_data

docker run -d \
  --name suitecrm \
  --restart unless-stopped \
  -p 8080:80 \
  -v suitecrm_data:/var/lib/suitecrm \
  -e SUITECRM_HOST=database.example.internal \
  -e SUITECRM_PORT=3306 \
  -e SUITECRM_DATABASE=suitecrm \
  -e SUITECRM_USER=suitecrm \
  -e SUITECRM_DB_PASSWORD='change-me' \
  -e SUITECRM_USERNAME=suitecrm \
  -e SUITECRM_PASSWORD='change-me' \
  -e [email protected] \
  -e SUITECRM_SITE_URL=https://crm.example.com \
  -e SUITECRM_ENABLE_HTTPS=yes \
  -e SUITECRM_DEMO_DATA=no \
  -e PHP_MEMORY_LIMIT=512M \
  -e PHP_UPLOAD_MAX_FILESIZE=100M \
  -e PHP_POST_MAX_SIZE=110M \
  -e PHP_MAX_EXECUTION_TIME=300 \
  -e TZ=America/Chicago \
  azuretechllc/suitecrm:8.0.0

⁠First startup

A fresh container validates its configuration and database state and then runs the SuiteCRM installation process automatically.

The database must exist/be reachable and the configured application database account must have the permissions required by the SuiteCRM installer.

The image refuses a destructive fresh installation when the configured database already contains tables but safe managed installation state cannot be established.

After successful installation, persistent state is saved under /var/lib/suitecrm. Recreating the application container with the same persistent volume and database should be treated as an existing installation rather than a fresh install.

⁠Reverse proxy deployment

The image may be placed behind Nginx, Nginx Proxy Manager, Cloudflare, another reverse proxy, or a compatible load balancer.

Set SUITECRM_SITE_URL to the public URL during the original installation, for example:

https://crm.example.com

The Apache configuration recognizes forwarded HTTPS information. TLS termination and certificate management are deployment concerns and do not require the SuiteCRM application container itself to own the public certificate.

⁠Health check

The image includes a Docker health check. It verifies required installed-state evidence and an HTTP application response and rejects recognized installer responses.

Inspect status with:

docker inspect --format '{{json .State.Health}}' suitecrm

⁠Logs

View container logs with:

docker logs -f suitecrm

Project diagnostics identify components such as entrypoint, configuration, lifecycle, installation, persistence, database, PHP, Apache, cron, worker, SMTP, backup, and health.

Sensitive supported values are redacted in project-generated effective-configuration diagnostics.

⁠Backup

Create a validated backup from a running container:

docker exec suitecrm /opt/suitecrm/bin/suitecrm-backup

Recovery points are stored under the persistent SuiteCRM volume:

/var/lib/suitecrm/backups/<version>/<timestamp>/

The backup contains a database dump plus applicable persistent configuration/mutable state and a manifest. A backup is not used as the normal mechanism for upgrading SuiteCRM.

⁠Restart and recreation

For an existing installation, keep both:

1. the same SuiteCRM persistent volume/bind mount; and
2. the same application database.

Do not delete the persistent SuiteCRM state while retaining an installed database and expect the container to perform a destructive fresh installation.

Install-only environment values are not a synchronization mechanism. Change administrator-owned SuiteCRM settings through SuiteCRM after installation unless a documented lifecycle operation explicitly says otherwise.

⁠Ports

The application serves HTTP on container port:

80

Map it to the host port appropriate for your deployment, commonly 8080:80.

Public HTTPS is commonly terminated at a reverse proxy. A published 443 mapping alone does not enable TLS inside the image.

⁠Production recommendations

• use an exact SuiteCRM image tag;
• use strong unique database, administrator, and SMTP credentials;
• keep the SuiteCRM and database persistent volumes backed up;
• place public deployments behind HTTPS;
• use a dedicated SuiteCRM database account instead of database root;
• do not expose the database port publicly unless required;
• keep production on the production image rather than -dev;
• keep Xdebug disabled outside development;
• review container logs after first installation and after image changes;
• preserve the same persistent SuiteCRM state and database across container recreation.

⁠SuiteCRM application configuration

After installation, SuiteCRM application settings are normally managed through SuiteCRM itself. The Docker environment is intentionally not a generic reconciliation engine for every SuiteCRM setting.

Only documented runtime/process variables remain automatically mutable.

⁠Supported deployment systems

The image is intended for Docker Engine, Docker Compose, Portainer, and other Docker-compatible deployment systems. Kubernetes is not required by this project.