If you need a clean Install Etherpad Fedora 44 guide, this article gives you a production-minded setup from the view of a Linux sysadmin. It covers the full flow, from system prep to service management, firewall access, and reverse proxy tuning, with each step explained by both what it does and why it matters. Etherpad runs on Node.js and uses configurable settings for ports, database type, and proxy behavior, so a careful setup saves time later.

Etherpad is a real-time collaborative editor, and Fedora 44 gives you a modern Linux base with systemd and firewalld built in. That makes it a strong fit for teams that want a self-hosted pad server instead of relying on a third-party service. The key is to install it in a way that is secure, maintainable, and easy to troubleshoot.

This guide assumes you want a practical Etherpad Fedora 44 setup that works for beginners but still meets the expectations of developers and sysadmins. You will see exact terminal commands, expected outputs, and configuration choices that line up with how Etherpad and Fedora actually behave. The final result is a deployable Linux server tutorial, not a quick demo that breaks after reboot.

Prerequisites

• Fedora 44 installed and updated.
• A user with sudo access or root access.
• Internet access for package installation and source download.
• A domain name if you plan to add Nginx and HTTPS.
• Basic comfort with the terminal and a text editor such as nano or vim.
• Enough disk space for Node.js packages, Etherpad files, and logs.

Step 1: Update Your System

Refresh packages first

Start by updating Fedora so you begin with the latest security fixes and package metadata.

sudo dnf upgrade --refresh -y

This command updates installed packages and refreshes repository data. You do this first because dependency issues are much easier to avoid than to debug later. On Fedora, a current package set also helps reduce surprises when you install Node.js build tools and service components.

Check the result

A successful run usually ends with a summary like this:

Complete!

If the system asks for a reboot after a kernel or core library update, do it before moving on. A reboot is not always required, but it is smart after major platform updates because it ensures your runtime matches your updated packages.

Step 2: Install Required Packages

Install the build and runtime tools

Etherpad needs Git, Node.js support, and some build helpers.

sudo dnf install -y git curl python3 gcc make openssl-devel

This installs the tools Etherpad and its dependencies often need during setup. Git fetches the source, curl helps with download or verification tasks, and the compiler tools support native module builds. openssl-devel is important because some Node packages and secure transports depend on OpenSSL headers.

Why this step matters

If you skip these packages, the install can fail during dependency compilation or later when Etherpad tries to start. A clean build environment is one of the easiest ways to keep an Install Etherpad Fedora 44 guide reliable. It also makes troubleshooting much easier because you know the platform tools are present.

Step 3: Install Node.js

Install the runtime

Etherpad is a Node.js application, so it cannot run without Node and npm support.

sudo dnf install -y nodejs npm

This installs the runtime Etherpad uses to launch the server and manage JavaScript dependencies. You need Node.js because Etherpad is not a static web app, it is a live server process that handles editing, sync, and plugin logic. Fedora’s Node.js packaging is the easiest starting point for most users.

Verify the version

Check that Node is available:

node -v
npm -v

Expected output looks similar to:

vXX.X.X
X.X.X

You do not need the exact same version shown above, but you do need a working Node installation. If the command returns “command not found,” stop here and fix Node.js before moving forward.

Step 4: Create a Dedicated Etherpad User

Add a service account

Run Etherpad under its own user instead of root.

sudo useradd -r -m -d /opt/etherpad -s /bin/bash etherpad

This creates a system user and a home directory for the app. You do this because a dedicated account limits damage if the service is ever compromised. It also keeps file ownership clean and makes service management more predictable.

Confirm the account

Check the account details:

id etherpad

Expected output:

uid=... etherpad

A separate user is not just a nice practice, it is a baseline security control. For any production configure Etherpad Fedora 44 plan, service isolation should come before web exposure.

Step 5: Download Etherpad

Clone the official source

Switch to the service user and clone the project.

sudo -iu etherpad
cd /opt/etherpad
git clone https://github.com/ether/etherpad-lite.git etherpad-lite
cd etherpad-lite

This pulls Etherpad from the official repository instead of a third-party mirror. You want the upstream source because it is the most trustworthy place for current code, release notes, and setup behavior. A source clone also makes future upgrades easier to manage.

Check the folder

List the files to confirm the clone worked:

ls -la

You should see project files such as bin/, settings.json.template, and src/. That tells you the repository is in place and ready for configuration.

Step 6: Install Etherpad Dependencies

Install application dependencies

Run the built-in dependency installer.

./bin/installDeps.sh

This script installs the Node modules Etherpad needs to run. You do this because cloning the repository does not yet give you a fully runnable server. The script resolves the package set Etherpad expects and prepares the app for launch.

What success looks like

When the script finishes, you should see messages about installed packages and no fatal errors.

... installed successfully ...

If it stops with build errors, check whether the compiler tools and openssl-devel package are present. This step often reveals missing system packages early, which is useful because it prevents a bad startup later.

Step 7: Configure Etherpad Fedora 44

Create the settings file

Copy the template and edit it.

cp settings.json.template settings.json
nano settings.json

This gives you a local configuration file that Etherpad reads at startup. You should edit settings.json, not the template, because the template is a reference file and may change across releases.

Set the important values

Focus on these settings first:

"ip": "127.0.0.1",
"port": 9001,
"dbType": "dirty",
"trustProxy": true

Use 127.0.0.1 when you plan to place Etherpad behind Nginx, because it keeps the app off the public interface. port tells Etherpad which local port to listen on, dbType controls where pad data is stored, and trustProxy must be enabled if a reverse proxy will sit in front of Etherpad.

Why these settings matter

trustProxy is especially important because Etherpad uses proxy headers to handle secure cookies and client information correctly. Etherpad’s documentation and template both note that proxy-aware deployments need this setting for correct behavior. If you skip it, HTTPS sessions and log accuracy can break in subtle ways.

Optional production notes

For a quick local test, dirty works. For real use, a database backend such as PostgreSQL or MySQL is usually a better long-term choice because it gives you stronger durability and easier growth planning. The Etherpad docs show support for multiple database types, so choose one that matches your environment.

Step 8: Create a systemd Service

Write the service unit

Create a service file so Fedora can manage Etherpad like a normal daemon.

sudo nano /etc/systemd/system/etherpad.service

Add this content:

[Unit]
Description=Etherpad Collaborative Editor
After=network.target

[Service]
Type=simple
User=etherpad
Group=etherpad
WorkingDirectory=/opt/etherpad/etherpad-lite
ExecStart=/usr/bin/node /opt/etherpad/etherpad-lite/node_modules/ep_etherpad-lite/node/server.js
Restart=always

[Install]
WantedBy=multi-user.target

This makes Etherpad start under systemd instead of staying tied to your terminal session. You want systemd because it restarts failed services, starts on boot, and gives you standard logging through journalctl.

Reload and enable

Run the following commands:

sudo systemctl daemon-reload
sudo systemctl enable --now etherpad

daemon-reload tells systemd to read the new service file. enable --now starts Etherpad immediately and also launches it at boot, which is exactly what you want for a server app.

Check the status

Verify the service is active:

sudo systemctl status etherpad

Expected output includes:

active (running)

If the service fails, read the log instead of guessing. That gives you the real reason, such as a bad path, wrong Node version, or broken config file.

Step 9: Open the Firewall Port

Allow the Etherpad port

If you plan to access Etherpad directly, open the port in firewalld.

sudo firewall-cmd --permanent --add-port=9001/tcp
sudo firewall-cmd --reload

This tells Fedora’s firewall to allow inbound traffic on port 9001. You do this because Fedora blocks most incoming traffic by default, so the app may run locally but stay unreachable from the network.

Verify the firewall rule

Check the active rules:

sudo firewall-cmd --list-ports

You should see:

9001/tcp

Do not disable the firewall just to make the service work. Open only the port you need, because that keeps the server protected while still reachable.

Step 10: Test the Service

Open Etherpad in a browser

Go to:

http://SERVER_IP:9001

If the page loads, the core install is working. This test confirms that Node.js, the Etherpad process, and the firewall path all line up. It is the fastest way to prove the base installation works before adding more layers.

Test the logs if needed

If the page does not load, inspect logs:

sudo journalctl -u etherpad -f

This is useful because most startup issues appear there first. A missing dependency, bad file path, or permission problem usually shows up in the logs with enough detail to fix it fast.

Step 11: Add Nginx Reverse Proxy

Install Nginx

For a production deployment, place Nginx in front of Etherpad.

sudo dnf install -y nginx

Nginx gives you a clean public entry point, easier TLS setup, and better control over HTTP headers. It also lets Etherpad stay bound to localhost, which is safer than exposing the app port directly.

Create the proxy config

Create a site file such as:

sudo nano /etc/nginx/conf.d/etherpad.conf

Use this example:

server {
    listen 80;
    server_name pad.example.com;

    location / {
        proxy_pass http://127.0.0.1:9001;
        proxy_http_version 1.1;
        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_set_header Host $host;
        proxy_buffering off;
    }
}

This forwards browser traffic to Etherpad while keeping the backend private. You need X-Forwarded-Proto and related headers because Etherpad uses proxy awareness to generate correct links and secure cookies.

Restart Nginx

Apply the config:

sudo nginx -t
sudo systemctl restart nginx

nginx -t checks the syntax before restart. That matters because a small config typo can take the proxy offline, and syntax validation catches it before users notice.

Step 12: Add HTTPS

Install Certbot or use your preferred TLS flow

Once the proxy works, add HTTPS.

sudo dnf install -y certbot python3-certbot-nginx

TLS matters because Etherpad can carry sensitive team notes and edits. A public collaboration service should not send traffic in plain text, especially if people sign in or use the pad from untrusted networks.

Request the certificate

Run Certbot:

sudo certbot --nginx -d pad.example.com

After that, confirm the site loads over HTTPS. In Etherpad, proxy mode must remain enabled so cookies and request details behave correctly behind TLS termination.

Step 13: Final Verification

Check the full path

Test the application through the domain name:

https://pad.example.com

A successful load means the stack is complete: Fedora, Node.js, Etherpad, systemd, firewall, Nginx, and TLS. That is the end state you want for a stable How To Install Etherpad Fedora 44 deployment.

Confirm proxy behavior

If the browser or logs show wrong protocol links or odd cookie warnings, revisit trustProxy and the Nginx headers. Etherpad’s configuration template is explicit about proxy-aware deployments, so this is one of the first things to verify.

Troubleshooting

1. Etherpad will not start

Check the service log:

sudo journalctl -u etherpad -xe

This usually points to a wrong ExecStart, missing Node.js binary, or permission issue. The fix is often simple, but you need the log to see which part failed.

2. Port 9001 does not open

Confirm the app is running and the firewall rule exists.

sudo systemctl status etherpad
sudo firewall-cmd --list-ports

If the service runs but the port is blocked, the problem is firewalld, not Etherpad. Open the port again and reload the firewall rules.

3. Reverse proxy shows bad URLs

Check trustProxy in settings.json and make sure Nginx sends forwarded headers.

"trustProxy": true

Etherpad expects proxy-aware settings when SSL ends at Nginx. If this flag is wrong, cookies and generated links may behave incorrectly.

4. Permission denied errors

Make sure files belong to the etherpad user.

sudo chown -R etherpad:etherpad /opt/etherpad/etherpad-lite

This fixes cases where setup commands were run as root or another user. File ownership matters because the systemd service runs as etherpad, not as your login account.

5. Blank page or asset errors

Restart the service and verify that Node modules installed correctly.

sudo systemctl restart etherpad

If the issue remains, rerun the dependency install script. Etherpad depends on a clean Node.js dependency tree, so missing modules can break the interface even when the service appears to be up.