Install a full instance of SuiteCRM in roughly 2 minutes!

If you’re looking for a modern, container-native way to run SuiteCRM 8, I’ve put together an OpenShift-optimized deployment: https://github.com/ryannix123/suitecrm-on-openshift

Why OpenShift?

  • Enterprise Kubernetes without the ops burden — Built-in routing, TLS, logging, and monitoring out of the box

  • One-click deployments — No Helm charts to wrestle with; just oc apply and go

  • Runs as non-root — Hardened for OpenShift’s restricted security context (no privileged containers needed)

  • Auto-installation — Database schema loads automatically on first boot

Try it free on the Developer Sandbox

Red Hat offers a free 30-day OpenShift environment with 14 GB RAM and 40 GB storage — plenty for testing SuiteCRM with a MySQL backend:

:backhand_index_pointing_right: https://developers.redhat.com/developer-sandbox

The Sandbox currently runs OpenShift 4.20 (Kubernetes 1.33.5). Grab the oc CLI here: https://mirror.openshift.com/pub/openshift-v4/clients/oc/latest/

Quick Start

bash

oc new-project suitecrm
oc apply -f https://raw.githubusercontent.com/ryannix123/suitecrm-on-openshift/main/deployment.yaml

Feedback and PRs welcome!


Disclaimer: I work for Red Hat as a Solutions Architect, but this is a personal project — not an official Red Hat offering or supported product.

3 Likes


Red Hat OpenShift isan enterprise-grade hybrid cloud platform built on Kubernetes that simplifies building, deploying, and managing containerized applications consistently across on-premise, public cloud, and edge environments, offering a unified PaaS with integrated developer tools, CI/CD, security, and lifecycle management for a full stack of application services. It provides automated operations, integrates AI/ML, and supports virtual machines alongside containers, acting as a “Swiss Army knife” for modernizing applications at scale.


To support SuiteCRM:

Hey Ryan,

interesting approach.

How would you prepare the CRM for API (V8 / JSON) access and how to upgrade the CRM, once it’s running in production?

Hi Bastian.

SuiteCRM API Access:

The V8 API is already exposed through the OpenShift route — no additional configuration needed on the infrastructure side. For SuiteCRM 8, the endpoint is:

https://<your-route>/legacy/Api/V8/

To enable API access:

1. Generate OAuth2 keys (already done at build time in my image, but if you’re customizing):

oc exec deployment/suitecrm -- bash -c "cd /var/www/html/public/legacy/Api/V8/OAuth2 && openssl genrsa -out private.key 2048 && openssl rsa -in private.key -pubout -out public.key"

2. Create an OAuth2 client in SuiteCRM:

  • Admin → OAuth2 Clients and Tokens → New Password Client (or New Client Credentials Client)

  • Note your Client ID and Secret

3. Get an access token:

curl -X POST https://<your-route>/legacy/Api/access_token \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "password",
    "client_id": "YOUR_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET",
    "username": "admin",
    "password": "YOUR_PASSWORD"
  }'

4. Call the API:

curl https://<your-route>/legacy/Api/V8/module/Accounts \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

Upgrades

This is where containerized deployments require a different mindset. Here’s my recommended approach for now, although I haven’t had time to test it yet:

Option 1: Blue-Green (safest for production)

1. Back up your database:

oc exec deployment/mariadb -- bash -c 'mysqldump -u root -p"${MYSQL_ROOT_PASSWORD}" suitecrm' > backup.sql

2. Build a new image with the target version (update the ARG SUITECRM_VERSION=8.x.x in the Containerfile in my repo)

3. If you have your own OpenShift or Kubernetes cluster, deploy to a new namespace, restore the database, and run the upgrade:

oc exec deployment/suitecrm -- ./bin/console suitecrm:app:upgrade -t SuiteCRM-8.x.x
oc exec deployment/suitecrm -- ./bin/console suitecrm:app:upgrade-finalize -t SuiteCRM-8.x.x

4. Test, then switch the route to the new deployment

Option 2: In-place upgrade (simpler, but higher risk)

1. Back up the database and PVC data

2. Download the upgrade package into the running container:

oc exec deployment/suitecrm -- mkdir -p /var/www/html/tmp/package/upgrade
oc cp SuiteCRM-8.x.x.zip suitecrm-pod:/var/www/html/tmp/package/upgrade/

3. Run the upgrade commands:

oc exec deployment/suitecrm -- ./bin/console suitecrm:app:upgrade -t SuiteCRM-8.x.x
oc exec deployment/suitecrm -- ./bin/console suitecrm:app:upgrade-finalize -t SuiteCRM-8.x.x

What persists across upgrades (via PVC):

  • Database (MariaDB PVC)

  • Uploads (/var/www/html/public/legacy/upload)

  • Custom modules (/var/www/html/public/legacy/custom)

  • Configuration (config.php, config_override.php)

I’ll add a proper upgrade guide to the repo — thanks for pushing me on this!

What I’ve usually done before on containerized setups is:

  • DB dump & files backup
  • Install the whole system on a staging environment (VM / “real” Linux)
  • Upgrade on staging + test
  • Provision / build a new container setup with the new data
    Not nice / the container way at all - Suite isn’t really the perfect fit for a container setup.

As for the DB, there are some changes once in a while during upgrade (when 2FA was released for instance).

And one more thing for the new file fields:

The /uploads folder is important to persist as well during the upgrade:

You’re doing this on OpenShift because of your work background?
Do you have vanilla-Docker experience / ideas as well for those who don’t want to convert? :smiley:

Hey Bastian,

I hear what you’re saying on the container front. Stateful applications like SuiteCRM can be tricky to containerize, deploy, and manage on OpenShift/Kubernetes. One of the great benefits of deploying applications to OpenShift/Kubernetes is that it really forces people to adopt a DevOps mindset. i.e., adopting automation for the application’s lifecycle, CI/CD, etc. As I demonstrate in my video, you can deploy a fully functional instance of SuiteCRM in about 2 minutes! Kubernetes also lets people scale their deployments, though most don’t need to scale their applications or platforms.

I spent about 3.5 hours pair-programming with Claude to get SuiteCRM running on OpenShift. OpenShift is a unique implementation of Kubernetes because of its Security Context Constraints (SCCs), which prevent running container deployments as root. This security posture is almost mandatory for multi–tenancy.

You can run my deployment on anything, including Podman/Docker (Podman is more secure than Docker while also fully compatible). Podman is fully open-source, too. The PVCs will persist the data during upgrades. I’ll get working on documenting the upgrade process.

Ryan

Very interesting - thanks for the write up.
I’ve usually used rootless docker before to make it more secure.
For small projects, it’s usually fairly simple with an upgrade once in a while but not much in terms of custom coding, API etc.
For bigger projects, there needs to be more Linux admin work (which is often painful with Docker containers involved).

A clean CI / CD approach would be great to have.
So far, I haven’t taken the step from Docker to Podman or Kubernetes. I’ll wait for your upgrade docs with this one. :slight_smile:

1 Like

This is SuiteCRM v8, right? I think there are quite a few things missing here, the most glaring omission is the /extensions directory.

There are also old-school Module Builder custom modules in public/legacy/modules, side-by-side with the core modules (sigh… :roll_eyes: )

How are you handling these?:

  • vendor directory (composer)
  • the built front-end? (supposing there are extensions)

You’re absolutely right — thanks for the feedback. This is SuiteCRM v8, and my current deployment is optimized for fresh installs and demo/dev environments, not heavily customized production instances. I should have called that out.

Here’s what’s currently persisted via PVC:

Directory Persisted? Notes
/var/www/html/public/legacy/upload :white_check_mark: User uploads
undefined ---- ----
/var/www/html/public/legacy/custom :white_check_mark: Studio customizations, views, layouts
undefined ---- ----
config.php, config_override.php :white_check_mark: Configuration
undefined ---- ----
/extensions :cross_mark: SuiteCRM 8 extensions — not persisted
undefined ---- ----
/public/legacy/modules (custom) :cross_mark: Module Builder output — not persisted
undefined ---- ----
/vendor :cross_mark: Baked into image at build time
undefined ---- ----
Front-end build :cross_mark: Angular build baked into image
undefined ---- ----

SuiteCRM’s architecture (especially the legacy side) expects to write to the filesystem at runtime — installing extensions, Module Builder output, composer updates, front-end rebuilds. Containers are designed to be immutable, and here’s where worlds collide.

What works today

  • Fresh installs with no extensions

  • Light customizations via Studio (writes to custom/)

  • Demos, dev environments, and evaluations

What requires additional work

  • Extensions: Must be installed at image build time, not runtime

  • Module Builder modules: Need to be baked into a custom image or mounted via PVC

  • Composer packages: Run composer install during image build

  • Front-end changes: Rebuild Angular app during image build

My recommended approach for production customizations

Treat the container image as immutable:

  1. Fork my repo

  2. Add your extensions to /extensions in the build context

  3. Add custom modules to the appropriate directories

  4. Update the Containerfile to run composer install and front-end builds

  5. Build and push your custom image

  6. Deploy using your image

This fits the container philosophy and enables proper CI/CD — every deployment is reproducible from the image.

I’ve updated the README with a “Customizations” section that’s honest about these trade-offs. Appreciate you pushing on this — it makes the project better.

1 Like

Quick update: I added a GitHub Actions workflow to keep the container up to date with the latest SuiteCRM version. Much easier than manually running podman build && podman push. :slight_smile: