A small CMS, growing thoughtfully.Download RenewCMS
Documentation

Search guide headings, settings and commands.

Operate and maintain RenewCMS

Configure storage, back up and restore your data, and troubleshoot your deployment.

Browse documentation

Choose database and media storage

SQLite and local uploads are the defaults. The Compose setup persists both in the renewcms-data volume. For a standalone binary, choose stable paths with DB_FILE and UPLOAD_DIR. Keep the data directory writable by the service user.

PostgreSQL, MySQL and MariaDB are available for external database storage. An S3-compatible bucket can store uploads independently of the database. Use the configuration reference served by your deployment at /llms/configuration.md to check the environment variables for your version before switching storage.

Configure PostgreSQL, MySQL or MariaDB

Create an empty database and a dedicated user with rights to create and migrate its schema. Set DB_DRIVER to postgres or mysql (including MariaDB), then set DB_HOST, DB_PORT, DB_USER, DB_PASSWORD and DB_NAME. Set DB_SSLMODE=verify-full for PostgreSQL or DB_TLS=true for MySQL when using a remote server with a trusted certificate.

If the database runs in another Compose service, DB_HOST is the service name. Changing the driver does not move existing content. Prepare and test a migration and keep the original database until you have verified the new deployment.

Store media in an S3-compatible bucket

Create a private bucket. Set STORAGE_DRIVER=s3, S3_BUCKET and S3_REGION. For a compatible service outside AWS, set S3_ENDPOINT and enable S3_PATH_STYLE=true if the provider requires it. Use the service role or supply both S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY.

To move existing files, stop RenewCMS and copy the uploads into the bucket under the same names. If you set S3_KEY_PREFIX, include the trailing slash and copy into that prefix. Restart and verify that existing media still loads before removing any local copies.

Back up your instance

Keep a copy of the database, uploads, environment file and deployed version in a secure location away from the host. For SQLite, stop the service before copying the data directory or volume, then restart it. For a remote database, use a database-native dump and back up local uploads or the S3 bucket separately.

For the default Docker setup, replace VOLUME with the actual volume name from docker volume ls. Run these commands from the Compose directory and check that the archive contains both the SQLite database and uploads.

Bash
docker compose stop renewcms
docker run --rm -v VOLUME:/data:ro -v "$PWD:/backup" alpine tar czf /backup/renewcms-backup.tar.gz -C /data .
docker compose start renewcms

Restore into a test instance

Start with a fresh volume, directory or database on a separate deployment. With the service stopped, restore the backup to the configured data paths, restore uploads and set ownership for the service account. Restore the configuration and adjust PUBLIC_URL and SMTP for the test environment. Start with the version that made the backup, then verify login, articles and media before relying on the restore.

For a Compose test instance, first create the new container with docker compose create renewcms. Replace RESTORE_VOLUME below with that container’s empty data volume and run the extraction from the directory containing the backup. Then start the test service.

Bash
docker run --rm -v RESTORE_VOLUME:/data -v "$PWD:/backup:ro" alpine \
  sh -c 'tar xzf /backup/renewcms-backup.tar.gz -C /data && chown -R 10001:10001 /data'
docker compose start renewcms

Upgrade safely

Read the release notes and back up before an upgrade. For Docker, set the image tag you intend to run, then pull and recreate the service. For a binary deployment, replace the executable and restart the service. Migrations run on startup. Check /healthz and exercise your editorial and public routes after the upgrade.

Bash
docker compose pull
docker compose up -d
Download RenewCMS

Diagnose startup, login and mail

If /healthz fails, check docker compose logs renewcms or journalctl -u renewcms -n 50 for missing settings or unavailable storage. If login works locally but fails through the proxy, verify PUBLIC_URL, HTTPS and proxy headers. For missing verification or invitation emails, check the logs, SMTP credentials, sender address and spam folder.

Manage account data and retention

Users can request an export or delete their own account from their profile. Review activity log retention under Settings → Activity (90 days by default), and include backups, mail delivery and any external storage when documenting where personal data is held.