Wiki.js on VPS: Installation, Configuration, and Maintenance

Installing Wiki.js on a VPS involves deployment via Docker/Compose, setting up a reverse proxy with HTTPS, and subsequent maintenance, providing a powerful self-hosted knowledge management platform accessible from anywhere in the world.

Wiki.js is a modern, powerful, and extensible knowledge management system (Wiki) built on Node.js. It allows you to create, edit, and manage content using an intuitive interface, supporting various editors including Markdown, AsciiDoc, and WYSIWYG. Deploying Wiki.js on your own VPS provides full control over data, security, and performance, making it an ideal solution for companies, development teams, or individuals looking to create a centralized information repository.

In this comprehensive guide, we will cover every step: from system requirements and choosing the optimal VPS to a step-by-step installation of Wiki.js using Docker, configuring a reverse proxy with HTTPS, and subsequent system maintenance. We will also provide recommendations on VPS configuration to ensure your Wiki.js runs stably and quickly, even under high load.

What is Wiki.js and why is it an ideal solution for knowledge management on a VPS?

Wiki.js is one of the most modern and functional platforms for creating wiki sites, designed with the needs of today's users and administrators in mind. It is built on Node.js, which ensures high performance and flexibility. Unlike traditional wiki systems, Wiki.js emphasizes ease of use, extensibility, and integration with modern technologies. Deploying Wiki.js on a server, especially on a VPS, gives you full control over your knowledge base, its security, and accessibility.

Key Features and Benefits of Wiki.js

Wiki.js stands out from its competitors due to a number of key features:

• Variety of Editors: Supports Markdown, AsciiDoc, WYSIWYG (Visual Editor), and HTML. This allows users to choose the most convenient way to create and edit content.
• Flexible Authentication System: Integration with LDAP/AD, OAuth2 (Google, GitHub, GitLab, Microsoft), SAML, as well as local authentication. This makes Wiki.js suitable for use in corporate environments with existing user management systems.
• File and Media Management: The built-in file manager allows easy uploading, organizing, and embedding of images and other media files into articles.
• Version Control: Every change to an article is automatically saved, providing a complete history of changes and the ability to restore previous versions.
• Search and Navigation: Powerful full-text search and intuitive navigation by categories and tags help quickly find the necessary information.
• Customizable Interface: Ability to change themes, logos, and other design elements to match corporate branding.
• Extensibility: Support for plugins and modules to add new functionality, as well as an API for integration with other systems.

Who is Wiki.js self-hosted suitable for?

The Wiki.js self-hosted model on your own VPS opens up wide possibilities for various categories of users:

• Development Teams: For documenting code, APIs, project decisions, and technical specifications. This helps new team members integrate into projects faster and experienced members maintain up-to-date knowledge.
• Small and Medium Businesses: For creating an internal knowledge base, employee instructions, corporate policies, and FAQs. This reduces the load on support services and increases work efficiency.
• Educational Institutions: For organizing educational materials, lecture notes, reference guides, and student projects.
• Communities and Non-profit Organizations: For centralized information storage, meeting minutes, event plans, and collaborative project work.
• Individuals: For personal notes, diaries, recipe collections, or as a personal knowledge base for hobbies and interests.

By choosing Wiki.js on a VPS, you get not just a wiki, but a powerful tool for organizing and disseminating information, fully controlled by you. This is especially relevant if you value data privacy and configuration flexibility, which cloud services cannot always offer. You can read more about hosting differences in our article Containers vs VM vs Bare-metal: The Hosting Landscape in 2026.

System Requirements for Installing Wiki.js on a Server

Before proceeding with the Wiki.js installation, it's important to ensure that your server meets the minimum system requirements. Although Wiki.js is relatively lightweight, its performance directly depends on the resources you allocate to it, especially if active use and a large number of users are planned. Deploying Wiki.js on a server requires a careful approach to configuration selection.

Minimum and Recommended Hardware Resources

The choice of VPS hardware resources depends on the anticipated load: the number of users, content volume, and frequency of access. Here are general recommendations:

Minimum Requirements (for personal use or a small team of up to 5-10 people):

• Processor: 1 vCPU (virtual core) with a frequency of 2.0 GHz or higher.
• RAM: 1 GB. Wiki.js on Node.js uses memory quite efficiently, but for stable operation with the OS, database, and Docker container, 1 GB is the absolute minimum.
• Disk Space: 10-20 GB NVMe SSD. SSD significantly speeds up database operations and page loading. NVMe is preferable to SATA SSD.
• Network Bandwidth: 100 Mbps.

Recommended Requirements (for medium-sized teams of up to 50 people or more active use):

• Processor: 2 vCPU with a frequency of 2.5 GHz or higher.
• RAM: 2-4 GB. This will ensure comfortable operation when several users are simultaneously editing and viewing articles.
• Disk Space: 40-80 GB NVMe SSD. This will allow storing more content, images, and provide room for growth.
• Network Bandwidth: 1 Gbps.

For Large Installations (over 50 users, intensive use):

• Processor: 4+ vCPU with a high clock speed.
• RAM: 8+ GB.
• Disk Space: 100+ GB NVMe SSD.
• Network Bandwidth: 1 Gbps.

It's important to remember that these requirements include resources for Wiki.js itself, the database, the Docker engine, and the operating system. It's always better to have a small reserve than to face resource shortages.

Required Software

For a successful Wiki.js installation on a VPS, you will need the following software:

• Operating System:
  • Preferred: Ubuntu Server (20.04 LTS or newer), Debian (11 or newer), CentOS Stream (8 or newer). These distributions are well-supported by Docker and have extensive documentation.
  • Important: A clean installation, without pre-installed web servers (Apache, Nginx), unless you plan to use them for other purposes.
• Docker Engine: The current stable version of Docker for your operating system. Wiki.js officially recommends a Wiki.js Docker installation, as it simplifies deployment and dependency management.
• Docker Compose: For orchestrating multiple Docker containers (Wiki.js, database) using a single configuration file.
• Database: Wiki.js supports several database types:
  • PostgreSQL (recommended): Version 9.5 or newer. This is the most preferred option for Wiki.js due to its reliability and performance.
  • MySQL/MariaDB: Version 5.7.8 / 10.2.7 or newer.
  • SQLite: Only for very small installations and testing, not recommended for production environments due to performance and scalability limitations.
  • MS SQL Server: Supported, but less common on Linux VPS.
  We will use PostgreSQL in conjunction with Docker.
• Reverse Proxy:
  • Nginx or Caddy. They will accept incoming requests and forward them to the Wiki.js Docker container, as well as provide SSL encryption (HTTPS).

Once you've ensured your VPS meets these requirements, you're ready for the next step – preparing the server for Wiki.js deployment.

Preparing Your VPS for Wiki.js Docker Image Installation

Before proceeding with the actual Wiki.js installation, you need to prepare your virtual server. This stage includes selecting the operating system, its basic configuration, and installing necessary software such as Docker and Docker Compose. Using a Wiki.js Docker image significantly simplifies the process by isolating the application with all its dependencies.

Choosing and Configuring the Operating System

As mentioned earlier, Debian/Ubuntu-based distributions are ideal for deploying Wiki.js. We will use Ubuntu Server 22.04 LTS as the most popular and well-documented option.

1. Accessing Your VPS:
Connect to your VPS via SSH. You will need the server's IP address and credentials (username/password or SSH key).

ssh user@your_vps_ip_address

2. System Update:
After connecting, the first step is to update all installed packages to their latest versions. This will ensure the stability and security of your system.

sudo apt update
sudo apt upgrade -y

3. Firewall Configuration (UFW):
It is highly recommended to configure a firewall to restrict server access to only necessary ports. For Ubuntu, this is the Uncomplicated Firewall (UFW).

sudo apt install ufw -y
sudo ufw allow OpenSSH # Allow SSH connections
sudo ufw allow http # Allow HTTP (port 80)
sudo ufw allow https # Allow HTTPS (port 443)
sudo ufw enable
sudo ufw status

Ensure that SSH is allowed before enabling UFW, otherwise you might lose access to the server.

Installing Docker and Docker Compose

To deploy Wiki.js Docker containers, we need to install Docker Engine and Docker Compose.

1. Installing Docker Engine:
Remove old Docker versions if they exist:

for pkg in docker.io docker-doc docker-compose docker-ce docker-ce-cli docker-ce-rootless-extras docker-buildx-plugin docker-compose-plugin containerd.io; do sudo apt remove $pkg; done

Install the necessary packages for Docker installation:

sudo apt install ca-certificates curl gnupg lsb-release -y

Add Docker's official GPG key:

sudo mkdir -m 0755 -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

Add the Docker repository to APT sources:

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Update the package list and install Docker Engine, containerd, and Docker Compose (client):

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y

2. Verify Docker Installation:
Ensure Docker is installed and running correctly by running a test container:

sudo docker run hello-world

You should see the message "Hello from Docker!".

3. Add User to Docker Group (optional, but convenient):
To avoid using sudo every time you work with Docker, add your user to the docker group. Replace your_user with your username on the VPS.

sudo usermod -aG docker your_user

After executing this command, you need to log out of your SSH session and reconnect for the changes to take effect.

Your VPS is now ready for Wiki.js deployment using Docker Compose. This approach makes Wiki.js installation simple and reproducible, which is crucial for any self-hosted application.

Step-by-Step Wiki.js Installation on a VPS using Docker Compose

Using Docker Compose is the most recommended and efficient way to install Wiki.js on a VPS. It allows you to define all services (Wiki.js, database) and their configuration in a single YAML file, simplifying deployment and management. We will use PostgreSQL as the database, which is an optimal choice for Wiki.js on a server.

Configuring the docker-compose.yml file

Create a directory for your Wiki.js project and navigate into it:

mkdir wiki-js
cd wiki-js

Create the docker-compose.yml file:

nano docker-compose.yml

Insert the following content. Be sure to replace your_wiki_db_password with a strong password for your database and your_wiki_host with the domain name through which your Wiki.js will be accessible (e.g., wiki.yourdomain.com). If you haven't set up a domain yet, you can use the VPS IP address.

version: "3.5"

services:
  wiki:
    image: ghcr.io/requarks/wiki:2
    container_name: wiki-js
    restart: unless-stopped
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wiki
      DB_PASS: your_wiki_db_password # Replace with your strong password
      DB_NAME: wiki
      # URL of your Wiki.js. Important for correct link and redirect behavior.
      # Replace with your domain or IP address if no domain is set up.
      WIKI_HOSTNAME: your_wiki_host 
      WIKI_PORT: 3000 # Port inside the container
      # WIKI_BASE_URL: https://your_wiki_host # If you are using a subdirectory, e.g., /wiki/
    ports:
      - "3000:3000" # If you want direct access without a proxy, otherwise the port will be proxied
    volumes:
      - ./data/wiki:/wiki/data
    depends_on:
      - db

  db:
    image: postgres:13-alpine
    container_name: wiki-db
    restart: unless-stopped
    environment:
      POSTGRES_USER: wiki
      POSTGRES_PASSWORD: your_wiki_db_password # Must match DB_PASS above
      POSTGRES_DB: wiki
    volumes:
      - ./data/db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U wiki -d wiki"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  wiki_data:
  db_data:

File Explanations:

• version: "3.5": Specifies the Docker Compose file version.
• services:: Defines the services.
  • wiki:
    • image: ghcr.io/requarks/wiki:2: Uses the official Wiki.js image from the GitHub Container Registry.
    • container_name: wiki-js: The container name.
    • restart: unless-stopped: The container will automatically restart unless it was manually stopped.
    • environment:: Environment variables for configuring Wiki.js and connecting to the database.
    • ports: - "3000:3000": Maps container port 3000 to host port 3000. If you are using a reverse proxy, this port will not be directly accessible externally, but is needed for internal communication.
    • volumes: - ./data/wiki:/wiki/data: Mounts the ./data/wiki directory from the host into the container to store Wiki.js data (images, files, etc.).
    • depends_on: - db: Indicates that the wiki service depends on the db service and will be started after it.
  • db:
    • image: postgres:13-alpine: Uses the official PostgreSQL version 13 image (lightweight alpine version).
    • container_name: wiki-db: The database container name.
    • environment:: Variables for configuring PostgreSQL (user, password, database name).
    • volumes: - ./data/db:/var/lib/postgresql/data: Mounts the ./data/db directory from the host for persistent storage of database data.
    • healthcheck:: Database health check to prevent Wiki.js from trying to connect to a database that is not yet ready.

Starting Wiki.js and Initial Setup

After saving the docker-compose.yml file, you can start Wiki.js and PostgreSQL with a single command:

docker compose up -d

The -d flag means "detached mode", meaning the containers will be run in the background.

Check the status of the running containers:

docker compose ps

You should see both containers (wiki-js and wiki-db) in "running" status.

Initial Wiki.js Setup:

Now Wiki.js should be accessible at your VPS's IP address on port 3000 (e.g., http://your_vps_ip_address:3000). Open this address in your browser. You will see the Wiki.js initial setup page.

1. Database Selection: In the first step, ensure "PostgreSQL" is selected.
2. DB Connection Details: Enter the same details you specified in docker-compose.yml:
   • Host: db (the database service name in Docker Compose)
   • Port: 5432
   • Database: wiki
   • User: wiki
   • Password: your_wiki_db_password
   Click "Connect".
3. Administrator Setup: After successfully connecting to the DB, you will be prompted to create an administrator account. Enter a username, email address, and a strong password. Remember these details!
4. Installation Completion: After creating the administrator, Wiki.js will be ready for use. You will be redirected to the main page of your new wiki.

At this stage, the Wiki.js installation is complete. However, for secure and convenient use in production, you need to configure a reverse proxy with HTTPS. We will discuss this in the next section. If you want to learn more about deploying other self-hosted applications, check out our article on Linkwarden on a VPS: Installation, Configuration, and Maintenance.

Configuring Reverse Proxy and HTTPS for Wiki.js

Direct access to Wiki.js via port 3000 (e.g., http://your_vps_ip_address:3000) is not a secure or professional solution for a production environment. You need to configure a Reverse Proxy and ensure traffic encryption with HTTPS. This will not only enhance security but also make your site more trusted by search engines and users. We will cover configuration using Nginx and Caddy.

Before you begin, ensure you have a domain name pointing to your VPS's IP address (A and/or AAAA records).

Configuring Nginx as a Reverse Proxy

Nginx is a powerful, high-performance web server that is excellent for acting as a reverse proxy. It is stable, easy to configure, and widely used.

1. Installing Nginx:

sudo apt install nginx -y

2. Configuring Nginx for Wiki.js:
Create a new configuration file for your domain. Replace wiki.yourdomain.com with your actual domain name.

sudo nano /etc/nginx/sites-available/wiki.yourdomain.com

Insert the following content:

server {
    listen 80;
    listen [::]:80;
    server_name wiki.yourdomain.com; # Replace with your domain

    # Redirect HTTP to HTTPS (will be configured after certificate acquisition)
    return 301 https://$host$request_uri; 
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name wiki.yourdomain.com; # Replace with your domain

    ssl_certificate /etc/letsencrypt/live/wiki.yourdomain.com/fullchain.pem; # Path to your certificate
    ssl_certificate_key /etc/letsencrypt/live/wiki.yourdomain.com/privkey.pem; # Path to your private key

    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://127.0.0.1:3000; # Port where Wiki.js is accessible inside the VPS
        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;
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_request_buffering off;
        proxy_redirect off;

        # WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }
}

3. Activate Configuration and Check Syntax:

sudo ln -s /etc/nginx/sites-available/wiki.yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

4. Install Certbot for HTTPS (Let's Encrypt):
Certbot will automatically obtain and renew SSL certificates from Let's Encrypt.

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d wiki.yourdomain.com

Follow the Certbot instructions. It will automatically update your Nginx config, adding certificate paths and configuring HTTP to HTTPS redirection.

After this, your Wiki.js will be accessible at https://wiki.yourdomain.com.

Using Caddy for Automatic HTTPS

Caddy is a modern web server that automatically manages Let's Encrypt SSL certificates, making it very convenient for deployment. For a Wiki.js Docker container, Caddy can be a simpler solution.

1. Installing Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy -y

2. Configuring the Caddyfile:
Create or edit the /etc/caddy/Caddyfile file:

sudo nano /etc/caddy/Caddyfile

Clear its content and insert the following, replacing wiki.yourdomain.com with your domain:

wiki.yourdomain.com { # Replace with your domain
    reverse_proxy 127.0.0.1:3000 { # Port where Wiki.js is accessible inside the VPS
        header_up Host {host}
        header_up X-Real-IP {remote_ip}
        header_up X-Forwarded-For {remote_ip}
        header_up X-Forwarded-Proto {scheme}
        # WebSocket support
        header_up Upgrade {http.request.header.Upgrade}
        header_up Connection {http.request.header.Connection}
    }

    # Enable Gzip compression (optional)
    encode gzip

    # Logging (optional)
    log {
        output file /var/log/caddy/access.log
    }
}

3. Verify and Start Caddy:

sudo caddy validate
sudo systemctl reload caddy

Caddy will automatically obtain an SSL certificate from Let's Encrypt and launch your site over HTTPS. Your Wiki.js will be accessible at https://wiki.yourdomain.com.

Both reverse proxy options provide secure access to your Wiki.js self-hosted installation. The choice between Nginx and Caddy depends on your preferences and experience. Caddy is often chosen for its simplicity, while Nginx is preferred for its flexibility and extensive configuration options. Remember that stable operation of either of these systems requires sufficient memory and CPU resources allocated to your VPS. Installing Netdata on a VPS can be useful for monitoring these metrics.

Maintaining Wiki.js on a Server: Backups, Updates, and Monitoring

Deploying Wiki.js on a VPS is just the beginning. To ensure stable, secure, and up-to-date operation of your knowledge management system, you must regularly perform maintenance tasks: backups, updates, and monitoring. These steps are critically important for any self-hosted application.

Wiki.js Data Backup Strategies

Backup is the cornerstone of any production system. In the case of Wiki.js running on Docker Compose, you need to back up two main components:

1. PostgreSQL Database: Contains all text data of articles, metadata, users, and settings.
2. Wiki.js Files Directory: Contains uploaded images, files, and other static resources that you specified in volumes (e.g., ./data/wiki).

Recommended Backup Approach:

1. PostgreSQL Database Backup:
Use the pg_dump utility inside the PostgreSQL container. This ensures data consistency.

# Navigate to the directory where your docker-compose.yml is located
cd ~/wiki-js 

# Execute the backup command inside the db container
docker compose exec db pg_dump -U wiki wiki > ./backups/wiki_db_$(date +%Y%m%d%H%M%S).sql

This command will create an SQL dump of your database in the ./backups/ directory. Ensure the backups directory exists: mkdir -p ./backups.

2. Wiki.js Files Backup:
Simply copy the Wiki.js data directory.

# Navigate to the directory where your docker-compose.yml is located
cd ~/wiki-js 

# Create an archive of the Wiki.js files directory
tar -czvf ./backups/wiki_files_$(date +%Y%m%d%H%M%S).tar.gz ./data/wiki

3. Automating Backups:
Set up a cron job to regularly execute these commands. For example, for a daily backup at 03:00 AM:

crontab -e

Add the following line (replace /home/your_user/wiki-js with the path to your Wiki.js directory):

0 3 * * * cd /home/your_user/wiki-js && docker compose exec db pg_dump -U wiki wiki > ./backups/wiki_db_$(date +%Y%m%d%H%M%S).sql && tar -czvf ./backups/wiki_files_$(date +%Y%m%d%H%M%S).tar.gz ./data/wiki

4. Backup Storage:
Never store backups only on the same server as the live system. Regularly move them to remote storage (S3, Dropbox, another VPS) or to a local machine. Use rsync, scp, or specialized cloud storage utilities.

Wiki.js and Docker Container Update Process

Regular updates are important for new features, bug fixes, and security patches. The process of updating a Wiki.js Docker installation is relatively simple:

1. Before Updating:
Always perform a full backup of the database and files, as described above. This is your insurance against unforeseen issues.

cd ~/wiki-js
docker compose exec db pg_dump -U wiki wiki > ./backups/wiki_db_pre_update_$(date +%Y%m%d%H%M%S).sql
tar -czvf ./backups/wiki_files_pre_update_$(date +%Y%m%d%H%M%S).tar.gz ./data/wiki

2. Stop Wiki.js:

docker compose down

3. Update Docker Images:
Pull the latest versions of Wiki.js and PostgreSQL images:

docker compose pull

If you are using tags like :latest or :2 in your docker-compose.yml (as in our example), this command will update them to the freshest versions available under that tag. For PostgreSQL, we use :13-alpine, which means updates only within version 13.

4. Start the Updated Wiki.js:

docker compose up -d

Docker Compose will recreate the containers with new images, preserving your data because it is mounted to host volumes. Wiki.js will automatically perform necessary database migrations on its first start after an update.

5. Verification:
After starting, ensure that Wiki.js is working correctly and all data is accessible.

Monitoring Performance and Security

Monitoring allows you to timely identify performance, security, and availability issues. For Wiki.js on a server, this is critically important.

• System Resource Monitoring:
  • Use utilities like htop, top, free -h for a quick overview of CPU, RAM, and disk usage.
  • For more in-depth monitoring, consider installing Netdata on a VPS or Prometheus/Grafana.
• Docker Log Monitoring:
  • Check Wiki.js and PostgreSQL container logs for errors:

    docker compose logs -f wiki

    docker compose logs -f db

• Availability Monitoring:
  • Use external monitoring services (e.g., UptimeRobot, Healthchecks.io) that will check your domain's availability and notify you in case of outages.
• Security:
  • Regularly update the operating system, Docker, and the Docker images themselves.
  • Use strong, unique passwords for all accounts, especially for the Wiki.js administrator and the database.
  • Configure a firewall (UFW) to restrict port access.
  • Consider using Fail2Ban to protect against brute-force attacks on SSH and Nginx/Caddy.
  • If your Wiki.js contains sensitive information, consider enabling 2FA for administrative accounts if supported by Wiki.js or your authentication system.

Careful attention to maintenance ensures that your Wiki.js self-hosted will be a reliable and secure knowledge management platform for years to come.

Which VPS to Choose for Wiki.js: Configuration Recommendations for Real-World Load

Choosing the right VPS for Wiki.js is a key factor in ensuring the performance, stability, and scalability of your knowledge base. An incorrectly chosen configuration can lead to slow operation, frequent crashes, and overall user dissatisfaction. We will look at how to assess needs and suggest specific configurations.

Assessing Needs: From Small Team to Corporate Portal

To choose the optimal VPS, you need to clearly understand who will use Wiki.js and how:

1. Number of Users:
   • Small Team (up to 10 people): Primary use is content viewing, infrequent editing.
   • Medium Team (10-50 people): Active use, frequent views, regular editing by multiple users simultaneously.
   • Large Organization (50+ people): High load, many concurrent users, intensive read/write operations, possibly integrations with other systems.
2. Content Volume:
   • A few dozen articles, without many images — minimal requirements.
   • Hundreds of articles, many images, attached files — requires more disk space and RAM for caching.
   • Thousands of articles, extensive media library — will require significant resources, especially for the database and file storage.
3. Frequency of Use:
   • Used a few times a day — can manage with minimal resources.
   • Used constantly throughout the workday — requires stable performance.
   • Peak loads (e.g., after an announcement is sent) — a reserve of CPU and RAM is important.
4. Additional Services on VPS:
   • Do you plan to host other applications on the same VPS (e.g., Gitea, Firefly III, or a mail server)? If so, the overall resource requirements will significantly increase.

Comparative Table of Recommended VPS Configurations

The table below provides recommendations for choosing a VPS for Wiki.js on a VPS depending on the anticipated load. Prices are approximate and may vary among different providers.

Usage Scenario	vCPU	RAM (GB)	SSD (NVMe)	Bandwidth	Approx. Price/Month	Features
Personal / Small Team (up to 10 users)	1-2	1-2	20-40 GB	100 Mbps	$5 - $15	Economical solution for getting started. Sufficient for basic tasks.
Medium Team (10-50 users)	2-4	4-8	80-160 GB	1 Gbps	$15 - $40	Optimal balance of performance and cost. Handles simultaneous editing well.
Large Organization (50+ users)	4-8+	8-16+	200-500+ GB	1-10 Gbps	$40 - $100+	High performance for intensive use. Scalability potential.

Additional Recommendations when Choosing a VPS:

• Disk Type: Always choose a VPS with NVMe SSD. This is critically important for database performance and page loading speed. The difference in speed compared to regular SSDs or HDDs is enormous.
• Server Location: Choose a data center that is geographically closer to most of your users. This will reduce latency.
• Bandwidth: Ensure that the provider offers sufficient bandwidth. For most Wiki.js installations, a 1 Gbps connection will be more than enough, but very large organizations with many media files might require more.
• Monitoring: Choose a provider that offers convenient tools for monitoring VPS resource usage.
• Managed vs Self-managed: If you lack server administration experience, consider the Managed VPS option, where the provider handles some of the OS maintenance tasks. However, this will be more expensive. You can read more about this in the article Self-managed vs Managed VPS in 2026: What to Choose.

Remember, it's always better to start with a configuration that slightly exceeds your current minimum needs to have room for growth. Most VPS providers allow you to easily scale resources (CPU, RAM, disk) as needed, so you can always upgrade your plan if your Wiki.js starts to experience resource shortages.

Conclusion

Deploying Wiki.js on a VPS using Docker Compose is an effective and reliable solution for creating a powerful self-hosted knowledge base. By following this guide, you will be able to perform a complete Wiki.js installation, configure secure access via a reverse proxy with HTTPS, and ensure long-term system maintenance, including backups and updates. For most teams, an optimal choice will be a VPS with 2-4 vCPU, 4-8 GB RAM, and 80-160 GB NVMe SSD, which will ensure stable operation and sufficient room for the growth of your content and user base.