Tiki Wiki CMS Groupware 30.1 on AWS User Guide

Overview

This guide covers launching and using the Tiki Wiki CMS Groupware 30.1 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg BookStack, CMS, Blogs and Wikis listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Tiki Wiki CMS Groupware is a free and open source web application with more built-in features than any other: wiki pages with full history, articles, blogs, forums, file galleries, trackers (forms and databases), calendars, structures, categories and fine-grained permissions, all in one package with no plugins to collect.

The cloudimg image adds:

• The current long-term-support release, verified. Tiki 30.1 is on Tiki's 30.x LTS line (regular support until at least February 2028). It is the official release file, checked against the SHA-256 SourceForge publishes and, file by file, against a manifest of the whole shipped tree. Its vendored libraries are raised past their published security advisories within Tiki's own version ranges (league/commonmark, Symfony, phpseclib, Flysystem), and the dependency audit is a build gate.
• No reachable installer, no shared database. Tiki's browser installer sets up the site for whoever opens it first. This image ships no database at all (the MariaDB data directory is empty) and no database configuration, and the installer is removed and locked. Your instance's first boot initialises its own database and runs Tiki's own console install before the web server starts, so every secret Tiki creates (its signing secret among them) is your instance's own.
• Secrets of your instance's own, never on a command line. The database password, the admin password and the TLS key are generated on your instance; nothing from the image build is reused. Tiki's console reads the admin password from a file only it and root can read, never from its command line, so it never reaches a process list or a log.
• HTTPS from the first boot. nginx serves Tiki on port 443 with a certificate generated on your instance's first boot. Port 80 redirects to HTTPS, every session is HTTPS only, and Tiki's own absolute links use https.
• Fail closed. nginx does not start until first boot has finished; if first boot cannot complete, the site stays offline rather than open.
• Closed by default. Public registration is off, Tiki does not call home to check for new versions, and its server-side shell command scheduler task is locked off.
• Only Tiki's entry scripts run PHP. PHP runs only for Tiki's own top-level scripts; nothing below the top level ever runs as PHP. Tiki's configuration, templates, schema, installer and console are never served, and the code folders serve only static files such as styles, scripts, images and fonts. The folders PHP writes to and serves (temp/public, storage/public, the wiki image folders) are static only: every file gets nosniff and a sandboxing content security policy, and only passive types (images, PDF, fonts, audio and video) open in the browser.
• A rate-limited sign in. nginx allows 10 sign-in attempts a minute from one address (after a burst of 10), using the address of the connection, never a header a client sends.
• Links from other sites cannot act for you. The admin pages, Tiki's AJAX service, the log out, and every form sent through Tiki's router only work when they come from your site itself (Step 9).
• The real host and client address. nginx hands Tiki the host name you configure and nothing a request claims, and Tiki's site domain is set to it. nginx removes X-Forwarded-For, Client-IP and the other forwarding headers, and Tiki records the address of the connection.
• Hardened defaults. The whole Tiki folder belongs to root and PHP can only read it, except the folders Tiki writes to (temp, storage, the wiki image and tracker image folders). Root never runs Tiki's code: the cloudimg tools run Tiki's console as the web server's user. PHP cannot run shell commands or load native code, is confined to the site folder, and nothing it could write is executable. Tiki's scheduler runs every five minutes as the web server's user in a sandbox with the same limits. MariaDB has no network listener at all, nginx, PHP, MariaDB, first boot and the scheduler are blocked from the instance metadata service, the AMI requires IMDSv2, and requests for a host name the instance does not serve are dropped.
• Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: Tiki Wiki CMS Groupware 30.1 LTS (the upstream release, checksum verified), MariaDB 10.11, PHP 8.3 FPM, nginx, Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
• A security group that allows TCP 22 (SSH), TCP 443 (Tiki) and TCP 80 (redirects to HTTPS) from the networks that should reach them. Keep 22 to your own networks. Open 443 to your visitors for a public site, or only to your team while you build it.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Tiki Wiki CMS Groupware 30.1 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair and a security group as above. The root volume holds the site, the database and your uploads: size it for your content.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=tiki}]'

Step 2: Connect to your instance

ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

First boot takes about half a minute (it creates the database and runs Tiki's console install). Then nginx, PHP, MariaDB and the first boot unit are active, and Tiki's scheduler timer is waiting:

systemctl is-active nginx php8.3-fpm mariadb tiki-firstboot tiki-scheduler.timer

active
active
active
active
active

nginx serves ports 80 and 443; PHP and MariaDB listen on local sockets only, so the only open ports are 22, 80 and 443:

sudo ss -tlnp | awk 'NR==1 || /nginx|sshd|php|maria/' | awk '{print $1, $4, $6}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g'

State Local Peer
LISTEN 0.0.0.0:443 users:(("nginx"),("nginx"),("nginx"))
LISTEN 0.0.0.0:22 users:(("sshd"),("systemd"))
LISTEN 0.0.0.0:80 users:(("nginx"),("nginx"),("nginx"))
LISTEN [::]:443 users:(("nginx"),("nginx"),("nginx"))
LISTEN [::]:22 users:(("sshd"),("systemd"))
LISTEN [::]:80 users:(("nginx"),("nginx"),("nginx"))

How the download was verified, and that every shipped file is unchanged:

head -4 /usr/share/doc/tiki/RELEASE
cd /var/www/tiki && sudo sha256sum -c --quiet /usr/share/doc/tiki/TIKI-30.1.sha256 && echo "$(grep -c . /usr/share/doc/tiki/TIKI-30.1.sha256) shipped files match the manifest"
php -v | head -1
mariadb --version

Tiki Wiki CMS Groupware 30.1
source https://sourceforge.net/projects/tikiwiki/files/Tiki_30.x_Alpheratz/30.1/tiki-30.1.tar.gz/download
sha256 92c21d5b472f8233e6636d782d1951de20f5db64de9363da931f9a91afa13c0e
licence LGPL-2.1-only (license.txt sha256 ab1b0666be21c29d39a122891b423a1a9b8901f08cfb1501285cf80411c68c51)
37621 shipped files match the manifest
PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
mariadb  Ver 15.1 Distrib 10.11.14-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper

(Files Tiki writes later, such as uploads and caches, are not in the list; the check covers every file the image shipped.)

Step 4: Get your sign-in details

The credentials file holds the address Tiki is served as (your instance's public DNS name by default), the admin user name and password, and the database credentials, all generated on this instance. Show it with:

sudo cat /root/tiki-credentials.txt

TIKI_URL=https://ec2-<public-ip-dashed>.<region>.compute.amazonaws.com/
TIKI_ADMIN_USER=admin
TIKI_ADMIN_PASSWORD=<24 letters and digits>
TIKI_DB_NAME=tiki
TIKI_DB_USER=tiki
TIKI_DB_PASSWORD=<48 hexadecimal characters>

Step 5: Visit the site and sign in

Open TIKI_URL in your browser. The certificate is self signed (generated on your instance), so your browser warns once: compare the certificate's SHA-256 fingerprint with the one on the instance (sudo openssl x509 -in /etc/nginx/ssl/tiki.crt -noout -fingerprint -sha256) and continue, or install a certificate from your own certificate authority (Step 11). A fresh site shows the starter HomePage, an ordinary wiki page you can edit or replace:

Choose Log in and sign in with TIKI_ADMIN_USER and TIKI_ADMIN_PASSWORD:

Settings > Control Panels (tiki-admin.php) is where you turn Tiki's features on and off:

Open the admin pages from Tiki's menus: a link into them that comes from another site, a bookmark or the address bar is refused (Step 9), while the site's pages always open. The admin account can do everything; for editors, create accounts and groups with only the permissions they need.

Step 6: Build your site

Every page is a wiki page with full revision history. Edit a page with Edit; practise on the Playground page:

Wiki > List Pages shows every page, its author and its version:

Turn on further features under Control Panels > Features: articles, blogs, forums, file galleries, trackers, calendars, surveys and more. Uploads to file galleries are stored in the database by default; they can be moved to /var/www/tiki/storage under Control Panels > File Galleries.

Step 7: Settings and Tiki's console

Tiki's command line console runs as the web server's user through tiki-console:

sudo tiki-console preferences:get server_domain | sed -E 's/value .*/value <your host>/'
sudo tiki-console preferences:get allowRegister
sudo tiki-console preferences:get feature_version_checks
sudo cat /var/www/tiki/db/cloudimg-system.ini.php

Preference server_domain has value <your host>
Preference allowRegister has value n
Preference feature_version_checks has value n
<?php if (isset($_SERVER['SCRIPT_FILENAME']) && realpath($_SERVER['SCRIPT_FILENAME']) === __FILE__) { exit; } ?>
; cloudimg: Tiki system configuration (locked preferences; an administrator cannot change them in the control panel).
; Tiki's ShellCommand scheduler task runs arbitrary shell commands; it is never offered on this image.
[cloudimg]
preference.scheduler_shell_command = n
; HTTPS for every session (nginx serves Tiki over HTTPS only; port 80 redirects).
preference.session_protected = y
; Absolute links (canonical, OpenGraph, notification mail) use https.
preference.https_external_links_for_users = y

sudo tiki-console list shows every command (clearing caches, rebuilding the search index, database updates, users). Never pass a password to it as an argument; use tiki-set-password (Step 12).

The settings in /var/www/tiki/db/cloudimg-system.ini.php are Tiki's own system configuration: they override the database and are locked in the control panel. The file locks Tiki's shell command scheduler task off, keeps every session on HTTPS and makes Tiki's absolute links use https. Version checks (feature_version_checks) and registration (allowRegister) start off; an admin can switch them on in the control panel.

Step 8: Your data

Everything that makes your site lives in the tiki database in MariaDB, and uploaded files in /var/www/tiki/storage and /var/www/tiki/img/wiki_up. The caches in /var/www/tiki/temp are rebuilt automatically. Keep /var/www/tiki/db/local.php with your backup: it holds this site's database password.

Back up the database to a file only root can read (MariaDB's root signs in over the local socket without a password, so no password appears on the command line), and the files:

sudo sh -c 'umask 077; mysqldump --single-transaction tiki > /root/tiki-$(date +%F).sql'
sudo tar -C /var/www/tiki -czf /root/tiki-files-$(date +%F).tgz storage img/wiki img/wiki_up img/trackers db/local.php

For a whole-instance copy, snapshot the EBS volume.

Step 9: Security checks

Port 80 sends browsers to HTTPS, the health endpoint answers for load balancer checks, and the database configuration, the installer, the console, the templates, Tiki's source and stray PHP files in the writable folders are not reachable:

H=$(sed -n 's/^set \$tiki_host "\(.*\)";$/\1/p' /etc/nginx/tiki-host.conf)
curl -s -o /dev/null -w 'port 80: %{http_code} -> %{redirect_url}\n' --resolve "$H:80:127.0.0.1" "http://$H/tiki-index.php" | sed -E 's#https://[^/]+#https://<your host>#'
curl -sk --resolve "$H:443:127.0.0.1" "https://$H/healthz"
for p in /db/local.php /tiki-install.php /installer/tiki-installer.php /console.php /templates/tiki-login.tpl /lib/tikilib.php /tiki-check.php /temp/public/x.php; do
  curl -sk -o /dev/null -w "$p: %{http_code}\n" -H 'Sec-Fetch-Site: same-origin' --resolve "$H:443:127.0.0.1" "https://$H$p"
done
curl -s -o /dev/null -w 'unknown host name: %{http_code}\n' -H 'Host: example.com' http://127.0.0.1/ || true

port 80: 301 -> https://<your host>/tiki-index.php
ok
/db/local.php: 404
/tiki-install.php: 404
/installer/tiki-installer.php: 404
/console.php: 404
/templates/tiki-login.tpl: 404
/lib/tikilib.php: 404
/tiki-check.php: 404
/temp/public/x.php: 404
unknown host name: 000

(000 means nginx closed the connection without an answer.) An admin page opens when the request comes from your own site, and is refused when it comes from anywhere else (another site, a bookmark, the address bar); the same applies to anything sent to Tiki's router, so a link or a form on another site cannot make your signed-in browser act on your Tiki:

H=$(sed -n 's/^set \$tiki_host "\(.*\)";$/\1/p' /etc/nginx/tiki-host.conf)
for s in same-origin cross-site none; do
  curl -sk -o /dev/null -w "admin page, Sec-Fetch-Site $s: %{http_code}\n" -H "Sec-Fetch-Site: $s" --resolve "$H:443:127.0.0.1" "https://$H/tiki-admin.php"
done
for s in same-origin cross-site; do
  curl -sk -o /dev/null -w "form sent to a page, Sec-Fetch-Site $s: %{http_code}\n" -H "Sec-Fetch-Site: $s" --data 'x=1' --resolve "$H:443:127.0.0.1" "https://$H/HomePage"
done

admin page, Sec-Fetch-Site same-origin: 302
admin page, Sec-Fetch-Site cross-site: 403
admin page, Sec-Fetch-Site none: 403
form sent to a page, Sec-Fetch-Site same-origin: 200
form sent to a page, Sec-Fetch-Site cross-site: 403

(200 or a redirect means Tiki answered; the admin page itself asks you to sign in when you are not.) The rules live in /etc/nginx/conf.d/cloudimg-xsite-guard.conf (pinned to your host name by tiki-set-hostname) and /etc/nginx/conf.d/cloudimg-tiki-guard.conf.

The credentials file is readable by root only, the database configuration by root and the web server only, and the Tiki code belongs to root; MariaDB has no network listener, PHP cannot shell out, and nginx, PHP, MariaDB, first boot and the scheduler cannot reach the instance metadata service:

sudo stat -c '%a %U:%G %n' /root/tiki-credentials.txt /var/www/tiki/db/local.php /var/www/tiki/tiki-index.php /var/www/tiki/temp
sudo mysql -N -e 'SELECT @@skip_networking, @@bind_address'
php-fpm8.3 -i 2>/dev/null | grep -E '^(disable_functions|open_basedir|ffi.enable) '
for u in nginx php8.3-fpm mariadb tiki-firstboot tiki-scheduler; do printf '%s: %s\n' "$u" "$(systemctl show -p IPAddressDeny --value $u)"; done

600 root:root /root/tiki-credentials.txt
640 root:www-data /var/www/tiki/db/local.php
644 root:root /var/www/tiki/tiki-index.php
750 www-data:www-data /var/www/tiki/temp
1   127.0.0.1
disable_functions => exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec,pcntl_fork,putenv,mail,dl => exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec,pcntl_fork,putenv,mail,dl
open_basedir => /var/www/tiki/:/var/lib/php/sessions/:/tmp/ => /var/www/tiki/:/var/lib/php/sessions/:/tmp/
ffi.enable => Off => Off
nginx: fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32
php8.3-fpm: fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32
mariadb: fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32
tiki-firstboot: fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32
tiki-scheduler: fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32

sudo tiki-cred-roundtrip signs in through the real sign-in form with the password from the credentials file and checks that wrong passwords are refused.

Step 10: Behind a proxy or load balancer

nginx removes X-Forwarded-For, X-Real-IP, Client-IP and Forwarded from every request, and Tiki reads the client address from the connection (feature_loadbalancer is off), so Tiki's logs and its sign-in protection use the address of the connection. Behind an AWS load balancer that is the load balancer's address; nginx's own access log (/var/log/nginx/access.log) records it the same way. To record visitors' addresses, use nginx's real_ip module with set_real_ip_from set to your load balancer's subnet only.

Step 11: Your own DNS name and certificate

Point a DNS record at the instance, then set the name Tiki is served as. This mints a new self signed certificate for the name, updates nginx (which hands the name to Tiki), the cross-site rule and Tiki's site domain, clears Tiki's caches, updates the address in /root/tiki-credentials.txt and keeps the name across reboots:

sudo tiki-set-hostname <your-domain>

To use a certificate from your own certificate authority instead, copy it over the generated pair and reload nginx (running tiki-set-hostname again replaces it with a self signed one):

sudo install -m 0644 <your-domain>.crt /etc/nginx/ssl/tiki.crt
sudo install -m 0600 <your-domain>.key /etc/nginx/ssl/tiki.key
sudo nginx -t && sudo systemctl reload nginx

Once browsers trust the certificate you can also add an HSTS header (add_header Strict-Transport-Security "max-age=31536000" always;) to /etc/nginx/snippets/cloudimg-tiki-headers.conf. The image does not send one: browsers ignore HSTS from a site whose certificate they do not trust.

Step 12: Passwords, e-mail, features and upgrades

tiki-set-password gives the admin account a new random password with Tiki's own console, signs out every session and records the password in /root/tiki-credentials.txt. Run it without arguments, or pass your own password (24 to 72 letters and digits) on stdin. Users change their own password under their preferences.

sudo tiki-set-password
printf '%s\n' '<your-new-password>' | sudo tiki-set-password --stdin

E-mail. The image ships no local mail server, and PHP's mail() is disabled. Set an SMTP server under Control Panels > General > Mail (choose SMTP as the mail sender) before you rely on notifications, password resets or invitations.

Features that stay off on this image. Tiki's server check page (tiki-check.php) is refused because it runs shell commands, which PHP cannot do here. Printing several pages or a whole structure as one document (tiki-print_pages.php, tiki-print_multi_pages.php) is refused until a Tiki release carries the permission fix that is already on Tiki's 30.x branch; you can lift the two lines in /etc/nginx/conf.d/cloudimg-tiki-guard.conf after upgrading to it. Tiki's in-browser template editor and theme writes need the templates and themes folders to be writable, which they are not here. Tiki's search-engine-friendly URL aliases for the AJAX service, log out, tracker fields and the REST API need same-origin proof like the pages they lead to; call tiki-api.php directly from scripts.

Upgrades. Take a snapshot first, replace the code with the new release's files (keep db/local.php, db/cloudimg-system.ini.php, storage and img), then run sudo tiki-console database:update and sudo tiki-console cache:clear all. After an upgrade, /usr/share/doc/tiki/TIKI-30.1.sha256 describes the old release, so the check in Step 3 then reports the changed files.

Step 13: Server components

Step 14: Security recommendations

• Allow port 22 in the security group from your own networks only.
• Keep the admin password secret and rotate it if it may have been shared (Step 12); give editors their own accounts with limited groups.
• Keep db/local.php and your database backups secret (Step 8).
• Use your own DNS name and a certificate your browsers trust (Step 11).
• Keep Tiki on the newest 30.x LTS release (Step 12).
• Keep the operating system patched; unattended security upgrades are on, and sudo apt-get update && sudo apt-get upgrade applies everything else. MariaDB and PHP-FPM with its zip, intl and bcmath extensions come from Ubuntu's universe repository; sudo pro security-status --esm-apps shows whether Ubuntu Pro (ESM Apps) has security updates for them (none were pending when the image was built).

Support and licensing

Tiki Wiki CMS Groupware is open source software by the Tiki Software Community Association under the GNU LGPL 2.1 (a copy is at /usr/share/doc/tiki/license.txt). The bundled libraries carry their own open source licences (in /var/www/tiki/vendor_bundled); the image leaves out one optional AGPL-licensed integration (the Kaltura video client) and documentation published under non-commercial licences. There is no per user or per CPU licence fee and no licence key. This image installs the upstream release, with the security updates of its bundled libraries described above, plus the cloudimg first boot, settings and helpers. The AMI price covers cloudimg's hardening, first boot setup and support.

• Email: support@cloudimg.co.uk
• Website: https://www.cloudimg.co.uk
• Support: 24/7, with a 24 hour response SLA