Installing xWiki on a cloud server for production use requires more than running a quick-start script and hoping for the best. A production-ready xWiki deployment involves selecting the right server resources, configuring a proper database backend, setting up a reverse proxy with SSL, and tuning the Java Virtual Machine for your expected workload. This guide covers two deployment paths -- Docker Compose and bare metal -- both optimized for MassiveGRID cloud servers but applicable to any Linux server running Ubuntu 24.04 LTS. Whether you are standing up a team wiki for fifty people or preparing infrastructure for a thousand-user enterprise deployment, the steps here will give you a solid, secure, and maintainable foundation.
The difference between a quick-start installation and a production deployment is significant. Quick-start guides get xWiki running on localhost with an embedded database and no encryption. Production deployments use PostgreSQL for data integrity, Nginx for SSL termination and static asset serving, proper JVM sizing for consistent performance, and firewall rules that limit the attack surface. If you are evaluating xWiki against Confluence and want to understand the broader platform differences before diving into installation, our xWiki vs Confluence enterprise comparison covers licensing, features, and total cost of ownership.
Server Requirements for Production xWiki
xWiki is a Java application that runs on Apache Tomcat and stores its data in a relational database. The resource requirements scale with your user count, content volume, and the number of extensions you install. Getting the initial sizing right prevents the frustrating experience of running out of memory or hitting CPU bottlenecks during peak usage.
Minimum Requirements for Small Teams (Up to 50 Users)
For small teams and evaluation deployments, a server with 4 CPU cores, 4 GB of RAM, and 50 GB of NVMe storage provides a workable baseline. This configuration handles basic wiki usage -- page editing, file attachments, and search -- without noticeable delays. The operating system should be Ubuntu 24.04 LTS, which provides long-term security updates and broad compatibility with the required software stack. You will need OpenJDK 17 as the Java runtime, Apache Tomcat 9 or 10 as the servlet container, PostgreSQL 15 or newer as the database, and Nginx as the reverse proxy for SSL termination.
Recommended Configuration for 50 to 200 Users
Organizations with 50 to 200 users should start with 8 CPU cores, 8 GB of RAM, and 100 GB of NVMe storage. This headroom accounts for concurrent editing sessions, search indexing operations, and the memory overhead of extensions like the WYSIWYG editor and diagramming tools. The additional cores allow PostgreSQL and Tomcat to handle parallel requests without contention, and the extra RAM prevents the JVM garbage collector from running too aggressively.
Choosing the Right MassiveGRID Plan
MassiveGRID's cloud server plans are well suited for xWiki deployments because resources scale independently. You can allocate more RAM without being forced into a higher CPU tier, or add NVMe storage without changing your compute configuration. For a small team deployment, a cloud server with 4 vCPUs and 8 GB RAM provides comfortable headroom. For larger deployments, a dedicated VPS with 8 cores and 16 GB RAM ensures consistent performance without noisy-neighbor effects from shared infrastructure. All MassiveGRID servers include NVMe storage by default, which makes a measurable difference in xWiki's responsiveness during search indexing and large page renders.
Docker Deployment with Docker Compose
Docker provides the fastest path to a production xWiki deployment. Containers encapsulate the application, database, and their dependencies, making the installation reproducible and the upgrade process straightforward. If you plan to run xWiki alongside other services or want simplified backup and migration workflows, Docker is the recommended approach.
Installing Docker and Docker Compose on Ubuntu 24.04
Start by updating your package index and installing the prerequisites for Docker's official repository. Add Docker's GPG key and repository source, then install the Docker engine and the Compose plugin. Once installed, add your user to the docker group so you can run commands without sudo. Verify the installation by running docker compose version to confirm that both the engine and Compose plugin are working.
sudo apt update && sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list
sudo apt update && sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo usermod -aG docker $USERCreating the Docker Compose Configuration
Create a project directory for your xWiki deployment and add a docker-compose.yml file. The configuration defines two services: the xWiki application container and a PostgreSQL database container. Named volumes ensure that both the wiki data and the database persist across container restarts and upgrades.
version: '3.8'
services:
xwiki:
image: xwiki:lts-postgres-tomcat
container_name: xwiki
depends_on:
- db
ports:
- "8080:8080"
environment:
- DB_USER=xwiki
- DB_PASSWORD=your_secure_password_here
- DB_DATABASE=xwiki
- DB_HOST=db
volumes:
- xwiki-data:/usr/local/xwiki
restart: unless-stopped
db:
image: postgres:15
container_name: xwiki-db
environment:
- POSTGRES_USER=xwiki
- POSTGRES_PASSWORD=your_secure_password_here
- POSTGRES_DB=xwiki
- POSTGRES_INITDB_ARGS="--encoding=UTF8 --lc-collate=en_US.UTF-8 --lc-ctype=en_US.UTF-8"
volumes:
- postgres-data:/var/lib/postgresql/data
restart: unless-stopped
volumes:
xwiki-data:
postgres-data:Replace your_secure_password_here with a strong, randomly generated password. The xwiki:lts-postgres-tomcat image bundles xWiki's Long Term Support release with the PostgreSQL JDBC driver and Tomcat, so no additional configuration is needed to connect the application to the database. Start the stack with docker compose up -d and monitor the logs with docker compose logs -f xwiki until you see the startup completion message.
Configuring Nginx as a Reverse Proxy with SSL
With xWiki running on port 8080 inside the container, you need Nginx in front of it to handle SSL termination, serve static assets efficiently, and provide a clean URL without the port number. Install Nginx and Certbot, then create a server block that proxies requests to the xWiki container.
sudo apt install -y nginx certbot python3-certbot-nginx
# /etc/nginx/sites-available/xwiki
server {
listen 80;
server_name wiki.yourdomain.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
client_max_body_size 100m;
}
}
sudo ln -s /etc/nginx/sites-available/xwiki /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d wiki.yourdomain.comCertbot will automatically modify the Nginx configuration to add SSL directives and set up automatic certificate renewal. The client_max_body_size directive allows large file uploads, which is important for wikis that store document attachments.
Bare Metal Deployment Step by Step
If you prefer direct control over every component or need to integrate xWiki into an existing server configuration, a bare metal deployment gives you full visibility into the stack. This section walks through each component installation in order.
Installing Java OpenJDK 17
xWiki requires Java 17 as its runtime. Install the headless JDK package, which excludes GUI libraries that a server does not need. Verify the installation by checking the Java version.
sudo apt update && sudo apt install -y openjdk-17-jdk-headless
java -versionInstalling and Configuring Apache Tomcat
Download the latest Tomcat 9 release and extract it to /opt/tomcat. Create a dedicated system user for Tomcat so that the servlet container runs with minimal privileges. Set the ownership of the Tomcat directory to this user and configure a systemd service unit for process management.
sudo useradd -r -m -U -d /opt/tomcat -s /bin/false tomcat
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.98/bin/apache-tomcat-9.0.98.tar.gz
sudo tar xzf apache-tomcat-9.0.98.tar.gz -C /opt/tomcat --strip-components=1
sudo chown -R tomcat:tomcat /opt/tomcatCreate the systemd service file at /etc/systemd/system/tomcat.service with the appropriate JVM options. Set the initial and maximum heap size to at least 2 GB for production use, and configure G1GC as the garbage collector.
Setting Up PostgreSQL
Install PostgreSQL 15 and create a dedicated database and user for xWiki. Use UTF-8 encoding to ensure proper handling of international characters in wiki content.
sudo apt install -y postgresql postgresql-contrib
sudo -u postgres createuser -S -D -R xwiki
sudo -u postgres psql -c "ALTER USER xwiki WITH PASSWORD 'your_secure_password';"
sudo -u postgres createdb -O xwiki -E UTF8 -l en_US.UTF-8 -T template0 xwikiDeploying the xWiki WAR File
Download the xWiki WAR distribution and deploy it to Tomcat's webapps directory. Also download the PostgreSQL JDBC driver and place it in xWiki's library directory. Edit xwiki.cfg to set the permanent directory and environment name, and configure xwiki.properties to point to the correct data directory. The Hibernate configuration file (hibernate.cfg.xml) needs to be updated with your PostgreSQL connection details -- uncomment the PostgreSQL section and comment out the default HSQLDB section.
JVM Parameters for Production
In your Tomcat service file or setenv.sh, configure the JVM parameters for production use. Set both -Xms and -Xmx to the same value to prevent heap resizing during operation. For a server with 8 GB of RAM, allocating 4 GB to the JVM is a reasonable starting point.
CATALINA_OPTS="-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -Djava.awt.headless=true"Nginx Reverse Proxy and First-Run Wizard
Configure Nginx as described in the Docker section above -- the reverse proxy configuration is identical regardless of whether xWiki runs in a container or directly on the host. Start Tomcat, then navigate to your domain in a browser to access the xWiki first-run wizard. The wizard will guide you through creating the admin account, selecting the default wiki flavor (Standard or Demo), and installing the initial set of extensions.
Post-Installation Configuration
With xWiki running and accessible over HTTPS, several post-installation steps harden the deployment for production use.
SSL/TLS with Certbot
If you have not already set up SSL during the Nginx configuration, run Certbot now. Every production wiki must serve traffic exclusively over HTTPS. Certbot's automatic renewal ensures that certificates stay current without manual intervention. Add an HTTP-to-HTTPS redirect in your Nginx configuration so that all traffic is encrypted.
Firewall Configuration with UFW
Ubuntu's Uncomplicated Firewall provides a straightforward way to restrict network access. Allow SSH, HTTP, and HTTPS traffic, then enable the firewall. Block direct access to Tomcat's port 8080 so that all traffic flows through Nginx.
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw statusJVM Tuning for Your Workload
The initial JVM settings from the installation section are a starting point. Monitor garbage collection behavior using GC logs and adjust the heap size based on actual usage patterns. For detailed guidance on optimizing JVM settings, PostgreSQL configuration, and caching behavior, see our xWiki performance tuning guide.
Backup Strategy
A production xWiki deployment needs regular backups of both the PostgreSQL database and the xWiki data directory (which contains attachments, extension data, and configuration files). Use pg_dump for database backups and rsync or a snapshot mechanism for the data directory. Schedule backups with cron and store them on a separate volume or remote storage. Test your restore procedure before you need it.
Monitoring
At minimum, monitor disk usage, memory consumption, CPU load, and Tomcat thread pool utilization. Tools like Prometheus with Grafana provide dashboards and alerting for these metrics. xWiki also exposes JMX metrics that can be scraped for application-specific monitoring such as active sessions, page render times, and cache hit rates.
Security Hardening
A default xWiki installation is functional but not hardened. Production deployments should address several security considerations to reduce the attack surface and protect wiki content.
Run Tomcat as a Non-Root User
The bare metal installation instructions already create a dedicated tomcat user with no shell access. Verify that Tomcat's systemd service runs under this user and that the user cannot escalate privileges. Never run Tomcat as root -- a vulnerability in the application would give an attacker full system access.
Restrict Database Access to Localhost
PostgreSQL should only accept connections from the local machine (or from the xWiki container in a Docker setup). Edit pg_hba.conf to ensure that the xWiki database user can only connect from 127.0.0.1 or the Docker network. Remote database connections should be disabled unless you have a specific architectural reason for them, such as a separate database server.
Authentication and Session Security
Configure xWiki to use secure cookies by setting the secure and HttpOnly flags in the cookie configuration. Set an appropriate session timeout -- long enough that users are not constantly re-authenticating, but short enough to limit exposure from abandoned sessions. If your organization uses LDAP or Active Directory, our xWiki LDAP and SSO configuration guide covers enterprise authentication integration in detail.
Content Security Policy Headers
Add Content-Security-Policy headers in your Nginx configuration to mitigate cross-site scripting attacks. Start with a restrictive policy and relax it as needed for specific xWiki functionality. Also add X-Content-Type-Options, X-Frame-Options, and Referrer-Policy headers for defense in depth.
Disable Unnecessary Features
Review the installed xWiki extensions and remove any that your organization does not use. Each extension increases the attack surface and consumes resources. Disable user registration if your organization manages accounts through LDAP or an external identity provider. Restrict wiki creation to administrators only.
The Managed Alternative: Let MassiveGRID Handle It
Everything described in this guide -- the installation, configuration, tuning, hardening, and ongoing maintenance -- represents real operational work. For organizations that want xWiki's capabilities without managing the underlying infrastructure, MassiveGRID's managed xWiki hosting provides a pre-tuned production stack that is ready from day one.
Managed deployments on MassiveGRID include a fully configured xWiki instance running on high-availability infrastructure with Proxmox HA clusters and Ceph distributed storage. The stack comes pre-tuned: JVM heap sizing, PostgreSQL configuration, Nginx caching, and SSL are all configured for your expected workload. Automated daily backups, 24/7 monitoring, and proactive patching mean that your team can focus on using the wiki rather than maintaining it. The 100% uptime SLA ensures that your knowledge base is always available, and 24/7 technical support is there when you need it.
For organizations planning large-scale deployments, MassiveGRID's infrastructure supports clustered xWiki architectures with multiple application nodes, load balancing, and database replication. Data centers in Frankfurt, London, New York, and Singapore provide low-latency access for distributed teams while meeting European data residency requirements for organizations subject to GDPR.
If you are ready to deploy xWiki on reliable infrastructure with expert support, explore MassiveGRID's xWiki hosting plans or contact our team to discuss your requirements.
Frequently Asked Questions
What are the system requirements for xWiki?
The minimum requirements for a production xWiki deployment are 4 CPU cores, 4 GB of RAM, and 50 GB of NVMe storage running Ubuntu 24.04 LTS with OpenJDK 17, Tomcat 9 or 10, and PostgreSQL 15. For organizations with 50 to 200 users, 8 cores, 8 GB RAM, and 100 GB storage is recommended. Larger deployments with 200 or more concurrent users should consider 16 cores, 16 GB or more RAM, and proportionally more storage.
How do I install xWiki with Docker?
Install Docker and Docker Compose on Ubuntu 24.04, create a docker-compose.yml file with the xwiki:lts-postgres-tomcat image and a PostgreSQL 15 container, configure environment variables for database credentials, and start the stack with docker compose up -d. Add an Nginx reverse proxy with SSL via Certbot for production access.
What database should I use with xWiki?
PostgreSQL 15 or newer is the recommended database for production xWiki deployments. It provides superior performance for xWiki's query patterns compared to MySQL, supports full UTF-8 encoding, and offers robust replication options for high-availability configurations. xWiki also supports MySQL and MariaDB, but PostgreSQL is the best-tested and most widely used option in enterprise deployments.
How much RAM does xWiki need?
The JVM heap should be at least 2 GB for small deployments, 4 GB for teams of 100 or more users, and 8 GB for deployments exceeding 500 users. The server itself needs additional RAM beyond the JVM allocation for the operating system, PostgreSQL, and Nginx. A server with 8 GB total RAM can comfortably allocate 4 GB to the JVM while leaving sufficient memory for other processes.
Is xWiki hard to install?
A Docker-based installation can be completed in under an hour by someone comfortable with Linux command-line tools. The bare metal installation takes longer because each component -- Java, Tomcat, PostgreSQL, Nginx -- is installed and configured separately. The installation itself is not inherently difficult, but production hardening, tuning, and ongoing maintenance require operational experience. MassiveGRID's managed hosting eliminates this operational burden entirely.
Can xWiki run on Ubuntu?
Yes. Ubuntu 24.04 LTS is the recommended operating system for xWiki production deployments. It provides long-term security updates, broad compatibility with Java, Tomcat, PostgreSQL, and Docker, and is well-documented for server use. Both the Docker and bare metal installation paths described in this guide use Ubuntu 24.04 as the base operating system.
Does xWiki need Tomcat?
Yes. xWiki is a Java web application packaged as a WAR file and requires a Java servlet container to run. Apache Tomcat 9 or 10 is the standard and best-supported option. The Docker deployment path handles this automatically -- the official xWiki Docker image includes Tomcat. In a bare metal deployment, you install and configure Tomcat manually as part of the setup process.
Written by MassiveGRID — As an official xWiki hosting partner, MassiveGRID provides managed xWiki hosting on high-availability infrastructure across data centers in Frankfurt, London, New York, and Singapore.