Learn Zellij - Multiplayer & Web Client

#Introduction

In episode 19 you brought Zellij to a distant server and made it resilient to dropped connections. Episode 20 closes the fifth phase of this series with one final, often overlooked step: sharing. We cover Multiplayer & Web Client — Zellij's ability to host many clients in a single session, share a session with others, and access it from a browser without installing anything.

Why does this feature matter? Terminal collaboration has always been painful manual work: screen-sharing with lag, copying commands back and forth, or taking turns typing. Zellij turns it into a native experience. A single session can be ridden by many people at once — each with their own cursor — and a colleague who hasn't even installed Zellij can join just via a URL in a browser. For pair programming, demonstrations, teaching, or inspecting production incidents, this changes everything. And because the entire feature runs on the client-server model you've known since episode 2, there are no confusing new concepts — just a different way of using them.

We'll cover six things: the multiplayer concept with many clients, the share plugin and session sharing UI, the read and write permission system for controlled collaboration, the 0.43 web client for browser access, web server configuration and security, and a ready-to-use pair programming flow. By the end of the episode, your terminal is no longer private — it can become a shared workspace, whenever you want.

#Multiplayer: One Session, Many Clients

From the start, Zellij was designed with a client-server model: one Zellij server can serve many clients attached to the same session. This isn't a trick; it's the architecture we discussed in episode 2, and multiplayer is just its natural consequence. Two terminals on the same machine can attach to the same session with the same command:

zellij attach pair

Two clients attached to the same session don't have to come from the same terminal. A colleague on another machine can join the same way, as long as both share access to the machine where the session runs — for example via SSH (episode 19) or via the web server we'll discuss. The point is, a Zellij client is just a window; the server holding the session can accept many windows at once, and all those windows stay synced to a single state.

Once two clients attach, both see the same screen and can send input. Cursor behavior is determined by the mirror_session option — if it's false (the default), each client has its own cursor; if true, the screen is mirrored so all clients see exactly what the host sees. This difference is important to understand before setting up a collaboration session.

#The Share Plugin & Session Sharing UI

To control who can join and by what route, Zellij provides the share plugin — a built-in interface for managing session sharing. Open it with Ctrl+o then s. From this single screen you can: start or stop the web server, share or unshare specific sessions, and create and manage authentication tokens.

When a session is shared, the share plugin displays the information you need to invite others — including the URL where the session can be accessed. This is the "session sharing UI" that makes collaboration seamless: no secret commands, all instructions appear on screen. An important part of this interface is token management:

zellij web
zellij web --create-token
zellij web --create-read-only-token

The zellij web command starts the web server, while the next two commands create tokens. Tokens created from the CLI and from the share plugin are the same thing — both are managed in a single authentication system, and can be revoked anytime with zellij web --revoke-token.

#Read & Write Permissions for Collaboration

Healthy collaboration needs access control. Zellij provides two clear permission levels, and both can be used from the terminal or the browser:

Read-only permissions were born from real need. When teaching or demonstrating, you want participants to see the terminal without the risk of them pressing the wrong key. Read-only tokens make this safe — participants watch the screen live, but can't send input or even resize the window:

zellij web --create-read-only-token --token-name observer

Picture a concrete case: you're handling a production incident and need a second pair of eyes from a more senior colleague. You share the session with a read-only token, the colleague observes the output live, and gives direction over voice — without the risk of their fingers pressing an unwanted key on a server that's already in trouble. That's the power of read-only permissions: collaboration without giving control, a boundary much appreciated in production environments.

Read-only tokens are also a great tool for screencasts, streaming, or when a client asks to "just see what's happening" on a production server. From the terminal side, zellij watch provides the same behavior: you watch the session flow in real-time without touching it.

#The Web Client: Access from a Browser

The most striking feature of this episode is the web client (introduced in 0.43): Zellij can be accessed from a browser without installing anything. All that needs to happen is Zellij's built-in web server running. Once the server is active, open http://127.0.0.1:8082 in a browser, enter the login token, and you'll see the Zellij welcome-screen — complete with a list of sessions you can attach or resurrect.

The beauty of the web client lies in its URL scheme. Every session has a bookmarkable URL: http://127.0.0.1:8082/session-name. When that URL is opened, Zellij looks for a session with that name:

1. If the session is running, you attach to it directly.
2. If the session has exited, Zellij resurrects it from the episode 17 data.
3. If it never existed, a new session with that name is created.

As a result, sessions become bookmarks like web pages — you can bookmark http://server:8082/ops and always land in the same work context, even after a total machine reboot. The web client also supports mobile browsers, so monitoring a session from your phone is no longer a fantasy.

#Web Server Configuration & Security

The Zellij web server is off by default — a deliberate security decision. You can enable it automatically every time Zellij starts via config.kdl:

web_server true
web_server_ip "127.0.0.1"
web_server_port 8082
enforce_https_on_localhost false
 
web_client {
    font "monospace"
    cursor_blink false
    cursor_style "block"
}

Notice the security logic. As long as the web server only serves 127.0.0.1, plain HTTP is still allowed — this is for easy local testing. Once you listen on another interface (web_server_ip "0.0.0.0"), HTTPS becomes mandatory, and you must provide certificates:

web_server_ip "0.0.0.0"
web_server_port 443
web_server_cert "/etc/zellij/certs/server.pem"
web_server_key "/etc/zellij/certs/server-key.pem"

There are two ways to start the web server — via the CLI or via configuration:

zellij web

web_server true

Certificates can be created with mkcert for local development, or official CA certificates when the service is exposed to a wider network. Zellij recommends placing the web server behind a reverse proxy like nginx when facing the internet, because the web server itself doesn't provide rate-limiting.

#The Pair Programming Flow

All the elements above come together in the most commonly used flow: pair programming. Here's the complete sequence you can copy:

1. Start a Zellij session on your machine: zellij -s pair.
2. Press Ctrl+o then s to open the share plugin, turn on the web server, and share the pair session.
3. Create a token: one read-write token for a colleague who's working with you, or a read-only token for someone who's only observing.
4. Send the URL and token to your colleague. They can join from a browser, or — if they have Zellij installed — directly zellij attach pair from their own terminal.
5. When the session ends, stop sharing in the share plugin, then revoke any unused tokens.

This flow works for both remote and local collaboration, and closes the loop we've been building since episode 0: a terminal that was once a private space is now a shared, controlled, safe workspace.

What sets this flow apart from mere screen-sharing is the real presence of each participant: your colleague can type in their own pane, open tabs, or just watch. No render lag, no manually managed turns — Zellij handles synchronization behind the scenes. After trying it a few times, you'll wonder why terminal collaboration ever felt so complicated.

#Common Pitfalls

1. Forgetting to turn on the web server. Opened the URL in a browser and see nothing? Make sure zellij web is running (or web_server true in config), and check its status with zellij web --status.
2. Sharing tokens with the wrong people. A full token means full control over your terminal. Use read-only tokens for observers, and never paste a full login token in a public chat.
3. Exposing the web server to the internet without HTTPS. Listening on 0.0.0.0 without a certificate will be rejected or unsafe. Prepare certificates and a reverse proxy before exposing the service.
4. Ignoring browser keybinding conflicts. Zellij shortcuts collide with browser shortcuts. Use the unlock-first preset (Ctrl+g) or switch to a terminal client for intensive work.
5. Leaving the web server running unattended. A live web server is an attack surface. Turn it off when unused, revoke old tokens, and limit shared sessions to only what's needed.

#Closing

In this episode 20 you've turned Zellij from a private workspace into a collaboration space. We started with the multiplayer concept of many clients, then managed sharing via the share plugin and session sharing UI. You understand the read and write permission system — from zellij attach and full tokens to zellij watch and read-only tokens — then saw how the 0.43 web client opens sessions from a browser through bookmarkable URLs. We closed with secure web server configuration and a ready-to-use pair programming flow.

The points to take away:

• One session can host many clients; mirror_session determines cursor mode.
• The share plugin (Ctrl+o then s) is the control center for session sharing and tokens.
• Read-only permissions protect observers: zellij watch in the terminal, read-only tokens in the browser.
• The web client gives every session a bookmarkable, resurrectable URL.
• The web server demands HTTPS and tokens; never expose it bare.

Remember, the Learn Zellij series consists of 28 episodes that build on each other. Your Zellij is now resilient, organized, and ready to collaborate — but what happens when Zellij meets Zellij, or when input has to push through stacked layers? In episode 21 we open the sixth phase: Nested Zellij & Advanced Input Handling — running Zellij inside Zellij, resolving keybinding conflicts with Locked mode, deeper mouse support, and integration with modern terminal features. See you in episode 21!