Skip to content
Klutch.sh Docs

How to Deploy Tiki Wiki CMS Groupware

Introduction

Tiki Wiki CMS Groupware is an open-source wiki-based content management system and groupware platform. Deploying Tiki Wiki CMS Groupware on Klutch.sh provides scalable, secure infrastructure for your collaboration and documentation needs, with support for persistent storage and automated CI/CD.

This guide covers deploying Tiki Wiki CMS Groupware on Klutch.sh using a Dockerfile, configuring persistent storage, and best practices for production deployments.

Prerequisites

  • A Klutch.sh account (sign up here)
  • A GitHub repository for your Tiki Wiki CMS Groupware deployment (or fork of the Tiki Wiki repo)
  • Basic knowledge of Docker and wiki/CMS concepts

1. Prepare your Tiki Wiki CMS Groupware repository

  • Fork or clone the Tiki Wiki CMS Groupware repository, or create a wrapper repo for your customizations.
  • Store large assets (such as configuration files, logs, or database files) outside the Git repo; use persistent volumes or object storage and mount or fetch them at runtime.

Refer to the Klutch.sh Quick Start Guide for repository setup and GitHub integration.

2. Sample non-Docker deployment (Klutch.sh build)

You can deploy Tiki Wiki CMS Groupware from your repo without a Dockerfile using Klutch.sh’s build system:

  1. Push your repo to GitHub. Include a start script (for example: start.sh) that installs dependencies and runs Tiki Wiki.
  2. In Klutch.sh, create a new project and app, and connect your repository.
  3. Set the start command to the script or Tiki Wiki’s start command (example: php-fpm or apache2-foreground).
  4. Attach persistent volumes for configuration, logs, or database files (see Volumes Guide).
  5. Set the app port to 80 (or your configured port).
  6. Click “Create” to build and deploy.

Notes:

  • Configure runtime secrets (database credentials, API keys) as environment variables in Klutch.sh.
  • For advanced use, customize the start script to load assets from mounted volumes or object storage.

A Dockerfile ensures reproducible builds and full control over dependencies. Example:

FROM tikiwiki/tikiwiki:latest


# Optional: Add custom configuration or plugins
# COPY ./config /var/www/html/config


EXPOSE 80

For custom assets, mount persistent volumes or fetch from object storage at startup.

4. Persistent storage & volumes

Tiki Wiki CMS Groupware requires persistent storage for configuration, logs, and database files:

  • Create a persistent volume in Klutch.sh and mount it to /var/www/html/config or your chosen path.
  • Configure Tiki Wiki (or your startup script) to read/write from the mounted path.

Example mount mapping in Klutch.sh app settings:

/var/www/html/config  <- my-tikiwiki-storage

If using object storage (S3-compatible), store credentials in environment variables and fetch assets at startup.

5. Environment variables and secrets

  • Store database credentials, API keys, and other secrets in Klutch.sh environment variables (never in the repo).
  • Use the Klutch.sh UI to mark secrets and prevent them from being logged.

6. Scaling, monitoring, and best practices

  • Use health checks and readiness probes if supported by Tiki Wiki.
  • Monitor CPU, memory, and latency; scale instances as needed.
  • Pin dependency versions and use multi-stage Docker builds for smaller images.
  • Use CI to build and publish images, or let Klutch.sh build from your repo and tag releases.
  • Restrict public access to endpoints; require authentication or place behind an API gateway.

Resources

Deploying Tiki Wiki CMS Groupware on Klutch.sh gives you a reproducible, scalable path to serve wiki-based CMS and groupware applications. For advanced setups, you can add a startup script to fetch assets from S3, a multi-stage Dockerfile for smaller images, or CI/CD integration to automate builds and deployments.