SuiteCRM 8.9.1 was installed on AWS Aurora Serverless, user accounts (with admin priv.s) created, original fake data cleared out, new data loaded. A few weeks later, suddenly:
user accounts (but not the original admin account) were mysteriously dropped
new data that had been loaded was mysteriously gone
the old fake data including the fake users were restored.
Anyone else experience this mysterious and frustrating occurrence? I’ve see it happen at least twice.
Hard to rely on SuiteCRM if this repeatedly happens.
I used AWS CDK to deploy the Mysqll DB on Aurora Serverless V2, and the PHP code on ECS Fargate. When CDK ran, it spun both up and connected, and initialized the state using the SuiteCRM fake data. Then we cleared out the fake data, imported real data and created user accounts.
After a few weeks, I tried to login (which i used to be able to do successfully) but the account was gone. I was able to login using the original admin account, but then could see that all the imported data was gone, and the fake data which had been cleared out was back in the database.
I believe what happened is that something triggered the ECS Fargate (i.e. Docker container) to get replaced with a new instance which had the default initialization behavior and fake data which caused it to re-initialize the state of the system seen upon initial spin-up. I think I need to find a way to persist the customized state (user accounts, Studio-modified structure, our imported data) so that a Docker container replacement doesn’t re-initialize but instead keeps the latest state.
Create a new file called entrypoint.sh in your project root:
#!/bin/bash
LOCK_FILE="/var/www/html/suitecrm/installed.lock"
CONFIG_FILE="/var/www/html/suitecrm/config.php"
echo "Checking installation status..."
if [ -f "$LOCK\_FILE" \] && \[ -f "$CONFIG_FILE" ]; then
# Already installed — skip initialization
echo "SuiteCRM already installed — skipping initialization"
else
# First time setup — run installer
echo "First time setup — running installer..."
# Run SuiteCRM original installer here
# (keep existing init logic)
# Create lock file after installation is complete
touch "$LOCK_FILE"
echo "Lock file created — initialization will be skipped on next startup"
fi
# Start web server normally
echo "Starting Apache..."
exec apache2-foreground
STEP 2 — Update the Dockerfile
Open your existing Dockerfile and add these lines at the bottom:
FROM php:8.1-apache
# ... other installation steps ...
# Copy entrypoint script into the image
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
# Use this script as the container entry point
ENTRYPOINT ["/entrypoint.sh"]
STEP 3 — Add EFS to your CDK Stack
Open your CDK stack file and add the following:
import * as efs from 'aws-cdk-lib/aws-efs';
// Create EFS filesystem to persist SuiteCRM data across container replacements
const fileSystem = new efs.FileSystem(this, 'SuiteCRMEFS', {
vpc: vpc, // Use existing VPC
removalPolicy: RemovalPolicy.RETAIN, // Retain data even if CDK stack is destroyed
encrypted: true, // Encrypt data at rest
performanceMode: efs.PerformanceMode.GENERAL_PURPOSE,
});
// Allow ECS service to connect to EFS
fileSystem.connections.allowDefaultPortFrom(
ecsService.connections
);
// Register EFS as a named volume in the Task Definition
taskDefinition.addVolume({
name: 'suitecrm-persistent',
efsVolumeConfiguration: {
fileSystemId: fileSystem.fileSystemId,
transitEncryption: 'ENABLED', // Encrypt data in transit
},
});
// Mount the EFS volume into the container at the SuiteCRM directory
container.addMountPoints({
sourceVolume: 'suitecrm-persistent',
containerPath: '/var/www/html/suitecrm', // SuiteCRM root directory inside container
readOnly: false,
});
What Each Step Does
Step
What it does
Step 1 — entrypoint.sh
Checks for installed.lock before running any init logic. If found, skips installer entirely
Step 2 — Dockerfile
Replaces the default startup command with your guarded script
Step 3 — CDK EFS
Creates a persistent volume outside the container so installed.lock and config.php survive container replacements
so basically, an old DB backup / version of the DB has been restored due to some server / environment settings or similar?
I’ve never seen this happening with SuiteCRM.
Try to replicate this on a standard / vanilla LAMP system, but I don’t think it’ll happen there.
I assume, that’s only an AWS topic.
I think this is basic Docker issue - if you don’t get things right regarding data persistence, and the container rebuilds, it’s a Brave New World where the past is forgotten.
The tricky part with SuiteCRM is separating the data that needs to be persisted. And the custom code.
I avoid using SuiteCRM with docker, for this reason. Except for quick test scenarios.
Thanks @nhat.thieu for the detailed answer. Disabling the re-install step when the Fargate (Docker) launches and sees data already in the DB is the right approach. I came to the same conclusion yesterday. And thanks for the code.
SuiteCRM state is tricky because SuiteCRM is an application that writes itself. When you change things in Module builder and Studio, it produces PHP code that will be executed as part of the app. So it’s not just database - some PHP code is also state that needs to be kept.
My way of thinking about this is: avoid the container mindset altogether. A SuiteCRM server is best though of as a constant thing, not one that gets “rebuilds”. What are the rebuilds for, anyway?
In other words, for me it’s a clear case for a full VM, not a container. Just leave it as it is.
