How to Install Nextcloud Talk on Ubuntu 24.04 VPS: Self-Hosted Calls + Chat

Nextcloud Talk turns your Nextcloud instance into a full-featured communication hub with chat rooms, audio calls, video calls, and screen sharing -- all self-hosted, end-to-end encrypted, and running entirely on infrastructure you control. This guide walks you through installing Nextcloud Talk alongside the Talk High Performance Backend (HPB), the signaling and media relay stack you need to host reliable group calls on your own Ubuntu 24.04 VPS.

Already running Nextcloud? This guide assumes you have a working Nextcloud installation. If you do not, start with our How to Install Nextcloud on Ubuntu 24.04 VPS guide first, then return here to layer on Talk.

Table of Contents

What is Nextcloud Talk?

Nextcloud Talk is the official real-time communication app for Nextcloud. It gives your users a Slack-like chat experience with persistent rooms, direct messages, file attachments, emoji reactions, and threaded replies, layered on top of WebRTC-based audio and video calls. Because it integrates natively with your Nextcloud user directory, there are no separate accounts, no new passwords, and no additional identity provider to manage -- the people already in your Nextcloud instance are already in Talk.

Out of the box, Talk uses a simple peer-to-peer (P2P) WebRTC mesh for calls. Every participant sends their audio and video stream directly to every other participant. This is fine for one-on-one conversations and small meetings of three or four people, but it breaks down quickly as the call grows. A ten-person call in mesh mode means each participant is encoding and uploading nine separate video streams simultaneously, which overwhelms typical home and office upload bandwidth and turns laptops into space heaters.

The Talk High Performance Backend (HPB) solves this by introducing a central media relay. Instead of every participant sending to every other participant, each participant sends a single stream to the HPB, and the HPB forwards streams to everyone else. This is called a Selective Forwarding Unit (SFU) architecture, and it is what powers Zoom, Google Meet, and Microsoft Teams under the hood. The HPB also handles signaling (the "who is in the call, who is speaking, who raised their hand" metadata) over WebSockets, which is dramatically more efficient than Nextcloud's default long-polling approach.

Why the High Performance Backend Matters

Running Nextcloud Talk without the HPB works, but it imposes hard limits. Here is what you gain by deploying the full stack:

• Scalable group calls -- A properly sized HPB supports 30-50+ participants in a single call. Mesh mode realistically caps out around 4-5 participants before quality collapses.
• Lower participant bandwidth -- Each user uploads one stream instead of N streams. A participant on a 10 Mbps connection can join a 20-person call without issue.
• Efficient signaling -- The signaling server uses persistent WebSocket connections instead of the default 30-second HTTP polling loop, reducing database load and latency when hundreds of chat rooms are active.
• Reliable NAT traversal -- A dedicated coturn server acts as both a STUN server (for discovering public IPs) and a TURN relay (for users stuck behind symmetric NAT or corporate firewalls). Without TURN, calls silently fail for users on restrictive networks.
• Screen sharing at full quality -- The Janus WebRTC gateway handles high-bitrate screen shares without choking on encoder duplication across peers.
• Recording and SIP dial-in readiness -- Optional Talk Recording backend and SIP dial-in bridges both require the HPB as their foundation.
• Federation support -- Cross-server Talk federation (launched in Nextcloud 29+) depends on the signaling server for cross-instance call setup.

When You Need the HPB

Prerequisites

Before you begin, make sure you have:

• A working Nextcloud instance on Ubuntu 24.04 (see our Nextcloud install guide if you need to set this up first)
• Root or sudo access on the VPS hosting Nextcloud
• SSH access via the built-in terminal on macOS/Linux or PuTTY on Windows
• A domain name for the signaling endpoint (for example talk.yourdomain.com) with an A record pointing to your VPS
• Nginx already configured as the web server for Nextcloud (see our Nginx install guide)
• Certbot / Let's Encrypt set up for issuing TLS certificates (see our Let's Encrypt guide)
• UFW firewall active (see our UFW configuration guide)
• At least 4 GB of RAM and 2 vCPU for a small deployment (10-15 concurrent call participants)
• A public IP address (TURN relays require a reachable public IP -- this will not work from behind NAT without port forwarding)

Recommended Plan: CloudCore Professional

For hosting Nextcloud + Talk HPB serving a team of 10-30 users with regular group calls, we recommend the CloudCore Professional plan:

- 6 vCPU cores

- 12 GB RAM

- 100 GB NVMe SSD

- Unmetered bandwidth on a 1 Gbps port

- Starts at EUR 19.99/month

Bandwidth is especially important for TURN relays -- a single 30-person call can push 100+ Mbps through your server in both directions.

Connect to your server via SSH:

ssh root@your-server-ip

Update system packages before installing anything new:

sudo apt update && sudo apt upgrade -y

Step 1: Install the Talk App in Nextcloud

The Talk application itself (the chat and basic calling UI) is installed as a standard Nextcloud app. You can enable it from the web admin panel, but doing it via the occ command-line tool is faster and scripts cleanly.

Switch to your Nextcloud installation directory and run occ as the web server user. Adjust the path if your Nextcloud lives elsewhere:

sudo -u www-data php /var/www/nextcloud/occ app:install spreed

Expected output:

spreed 20.0.5 installed
spreed enabled

The package is called spreed internally -- this is the historical name of the upstream project that became Nextcloud Talk. Verify it is enabled:

sudo -u www-data php /var/www/nextcloud/occ app:list | grep spreed

Expected output:

- spreed: 20.0.5

At this point, users can log into Nextcloud, open the Talk app from the top menu, create rooms, and start 1-on-1 calls. The next steps add the HPB so that group calls actually scale.

Step 2: Install NATS Messaging Server

The Nextcloud signaling server uses NATS as an internal message bus to coordinate events across signaling processes. Even on a single-node deployment, the signaling server requires a running NATS instance to start.

Install the nats-server package:

sudo apt install -y nats-server

Enable and start the service:

sudo systemctl enable --now nats-server

Verify it is running:

sudo systemctl status nats-server

Expected output (abbreviated):

● nats-server.service - NATS messaging server
     Loaded: loaded (/lib/systemd/system/nats-server.service; enabled)
     Active: active (running) since Thu 2026-04-16 10:05:00 UTC; 10s ago
   Main PID: 1501 (nats-server)

By default NATS listens on 127.0.0.1:4222, which is exactly what we want. No external exposure is needed or desirable.

Step 3: Install the Janus WebRTC Gateway

Janus is the WebRTC Selective Forwarding Unit that actually routes audio and video between call participants. The signaling server talks to Janus over a local Unix socket or WebSocket to instruct it which streams to forward where.

Install Janus and its dependencies from the Ubuntu repositories:

sudo apt install -y janus

Edit the main Janus configuration to enable the WebSocket transport that the signaling server expects:

sudo nano /etc/janus/janus.transport.websockets.jcfg

Find the general section and set:

general: {
    json = "indented"
    ws = true
    ws_port = 8188
    ws_ip = "127.0.0.1"
    wss = false
}

Binding Janus to 127.0.0.1 is deliberate -- Janus itself should never be exposed to the internet. The signaling server (on the same host) is the only thing that talks to it directly.

Next, edit the main Janus config to set the public IP used in ICE candidates:

sudo nano /etc/janus/janus.jcfg

Set nat_1_1_mapping to your VPS's public IP so Janus advertises the correct address in ICE candidates:

nat: {
    nat_1_1_mapping = "YOUR_PUBLIC_IP"
    keep_private_host = false
}

Also set a predictable RTP port range (we will open these in the firewall):

media: {
    rtp_port_range = "49152-65535"
}

Enable and start Janus:

sudo systemctl enable --now janus
sudo systemctl status janus

Expected output:

● janus.service - Janus WebRTC Server
     Active: active (running) since Thu 2026-04-16 10:10:00 UTC; 5s ago

Step 4: Install coturn (TURN/STUN Server)

coturn provides both STUN (discovering public IPs, cheap and stateless) and TURN (relaying media when a direct peer connection cannot be established, bandwidth-intensive). Users behind symmetric NATs, corporate firewalls, or double-NAT home setups depend on the TURN relay to complete calls.

Install coturn:

sudo apt install -y coturn

Enable the service to start on boot:

sudo sed -i 's/#TURNSERVER_ENABLED=1/TURNSERVER_ENABLED=1/' /etc/default/coturn

Generate a strong shared secret that coturn and Nextcloud will both use to authenticate TURN credentials:

openssl rand -hex 32

Copy the output -- you will paste it into both the coturn config and the Nextcloud Talk admin panel later.

Edit the coturn config:

sudo nano /etc/turnserver.conf

Replace the file contents with a minimal, secure configuration. Substitute your public IP, your domain, and the secret you just generated:

listening-port=3478
fingerprint
use-auth-secret
static-auth-secret=YOUR_GENERATED_SECRET_FROM_ABOVE
realm=talk.yourdomain.com
total-quota=100
bps-capacity=0
stale-nonce=600
no-loopback-peers
no-multicast-peers
no-cli
no-tlsv1
no-tlsv1_1
external-ip=YOUR_PUBLIC_IP
min-port=49152
max-port=65535
log-file=/var/log/turnserver/turnserver.log
simple-log

Key directives explained:

• use-auth-secret + static-auth-secret -- Enables time-limited credential mode. Nextcloud uses the shared secret to generate short-lived usernames/passwords for each user, so you never store per-user TURN credentials.
• min-port / max-port -- The UDP port range coturn uses for relayed media. These must be opened in the firewall.
• external-ip -- Required if coturn is behind any kind of NAT; harmless to set on a plain VPS with a single public IP.
• no-tlsv1 / no-tlsv1_1 -- Disable deprecated TLS versions.

sudo systemctl restart coturn
sudo systemctl enable coturn
sudo systemctl status coturn

Expected output:

● coturn.service - coTURN STUN/TURN Server
     Active: active (running) since Thu 2026-04-16 10:15:00 UTC; 3s ago

Step 5: Install the Nextcloud Signaling Server

The signaling server is nextcloud-spreed-signaling from Struktur AG, the same team that builds Talk. It is a Go binary that terminates WebSocket connections from Talk clients, authenticates them against your Nextcloud instance, and orchestrates Janus.

Ubuntu 24.04 ships a packaged version:

sudo apt install -y nextcloud-spreed-signaling

If the package is not available in your apt sources, install from the upstream APT repository:

curl -fsSL https://packagecloud.io/strukturag/nextcloud-spreed-signaling/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/strukturag.gpg
echo "deb [signed-by=/usr/share/keyrings/strukturag.gpg] https://packagecloud.io/strukturag/nextcloud-spreed-signaling/ubuntu noble main" | sudo tee /etc/apt/sources.list.d/strukturag.list
sudo apt update
sudo apt install -y nextcloud-spreed-signaling

Generate two more secrets -- one for Nextcloud-to-signaling auth, and one for signaling-internal auth:

openssl rand -hex 32   # Nextcloud <-> signaling shared secret
openssl rand -hex 32   # Internal signaling secret

Edit the signaling server config:

sudo nano /etc/signaling/server.conf

A minimal working configuration looks like this (replace placeholders with your actual values):

[http]
listen = 127.0.0.1:8080
[app]
debug = false
[sessions]
hashkey = RANDOM_32_BYTE_HEX_1
blockkey = RANDOM_32_BYTE_HEX_2
[backend]
backends = nextcloud
allowall = false
[nextcloud]
url = https://nextcloud.yourdomain.com
secret = YOUR_NEXTCLOUD_SIGNALING_SHARED_SECRET
[nats]
url = nats://localhost:4222
[mcu]
type = janus
url = ws://127.0.0.1:8188
maxstreambitrate = 1048576
maxscreenbitrate = 2097152
[turn]
apikey = RANDOM_TURN_API_KEY
secret = YOUR_COTURN_STATIC_AUTH_SECRET
servers = turn:talk.yourdomain.com:3478?transport=udp,turn:talk.yourdomain.com:3478?transport=tcp

Generate the two random hex values for hashkey and blockkey with openssl rand -hex 32. Both should be 64 hex characters (32 bytes) long.

Enable and start the signaling service:

sudo systemctl enable --now signaling
sudo systemctl status signaling

Expected output:

● signaling.service - Nextcloud Talk signaling server
     Active: active (running) since Thu 2026-04-16 10:20:00 UTC; 4s ago

Check the logs if it fails to start:

sudo journalctl -u signaling -n 50 --no-pager

The signaling server now listens on 127.0.0.1:8080. It is not yet accessible from the internet -- that is Nginx's job.

Step 6: Configure Nginx Reverse Proxy for Signaling

Talk clients need to open a WebSocket (wss://) connection to the signaling server. We front it with Nginx on a dedicated subdomain so it can share Let's Encrypt certificate renewal with the rest of your stack.

Create a new Nginx site configuration:

sudo nano /etc/nginx/sites-available/talk-signaling

Paste the following, substituting your domain:

upstream signaling_backend {
    server 127.0.0.1:8080;
    keepalive 16;
}
server {
    listen 80;
    server_name talk.yourdomain.com;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl http2;
    server_name talk.yourdomain.com;
    ssl_certificate     /etc/letsencrypt/live/talk.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/talk.yourdomain.com/privkey.pem;
    # Security headers
    add_header Strict-Transport-Security "max-age=31536000" always;
    add_header X-Content-Type-Options nosniff;
    # Signaling WebSocket endpoint
    location /standalone-signaling/ {
        proxy_pass http://signaling_backend/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        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;
        # WebSockets are long-lived; disable timeouts
        proxy_read_timeout 86400s;
        proxy_send_timeout 86400s;
        proxy_buffering off;
    }
    # Health check endpoint
    location = /standalone-signaling/api/v1/welcome {
        proxy_pass http://signaling_backend/api/v1/welcome;
    }
}

Enable the site, obtain an SSL certificate, and reload Nginx:

sudo ln -s /etc/nginx/sites-available/talk-signaling /etc/nginx/sites-enabled/
sudo certbot --nginx -d talk.yourdomain.com
sudo nginx -t && sudo systemctl reload nginx

Verify the welcome endpoint responds:

curl https://talk.yourdomain.com/standalone-signaling/api/v1/welcome

Expected output:

{"nextcloud-spreed-signaling":"Welcome","version":"1.3.4"}

If you see this JSON response, the signaling server is reachable from the public internet through Nginx.

Step 7: Open Firewall Ports

UFW needs to allow the TURN server, signaling TLS, and the Janus/coturn UDP media port range. If you already allow HTTPS for Nextcloud, do not duplicate that rule.

# HTTPS (Nextcloud + signaling endpoint)
sudo ufw allow 443/tcp
TURN/STUN server
sudo ufw allow 3478/udp
sudo ufw allow 3478/tcp
WebRTC media relay (used by both coturn and Janus)
sudo ufw allow 49152:65535/udp
Apply and check
sudo ufw reload
sudo ufw status

Expected output:

Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere
3478/udp                   ALLOW       Anywhere
3478/tcp                   ALLOW       Anywhere
49152:65535/udp            ALLOW       Anywhere

UDP 3478 is the primary TURN/STUN port. TCP 3478 is a fallback for users stuck behind firewalls that block all UDP (common in corporate networks). The UDP 49152-65535 range carries the actual relayed audio and video packets.

Step 8: Wire It All Up in Nextcloud Admin

With every backend service running, the final step is telling Nextcloud Talk how to reach them. Log into Nextcloud as an administrator and open Settings -> Administration -> Talk.

High Performance Backend

In the High-performance backend section:

• HPB server URL: https://talk.yourdomain.com/standalone-signaling/
• Shared secret: paste the value you used for [nextcloud] secret in /etc/signaling/server.conf
• Click Test this server -- you should see a green "OK" indicator.

TURN Servers

Scroll to the TURN servers section and click Add a new TURN server:

• Schemes: turn: and turns: (both)
• TURN server URL: talk.yourdomain.com:3478
• Shared secret: paste your coturn static-auth-secret
• Protocols: UDP and TCP

STUN Servers

In the STUN servers section:

• Remove the default stun.nextcloud.com:443 if you want to keep everything self-hosted.
• Add talk.yourdomain.com:3478.

Call Behavior

Under Call settings:

• Require a phone number on registration for guests: your preference
• Allow conversation mention of all participants: enabled for teams
• Default notification level: "All messages" for small teams, "Only @mentions" for larger deployments

You can also verify from the CLI that the Talk app has picked up the config:

sudo -u www-data php /var/www/nextcloud/occ talk:signaling:list

Expected output:

Server: https://talk.yourdomain.com/standalone-signaling/
Verify: true

Step 9: Test Call Quality

Open the Talk app in two different browsers (or two devices), start a call, and watch three things: video latency, the debug panel, and the TURN logs.

Verify WebSocket Signaling

Open the browser DevTools Network tab and filter by "WS". You should see a persistent WebSocket connection to wss://talk.yourdomain.com/standalone-signaling/spreed that stays open for the duration of the call. If you see repeating HTTP requests to /ocs/v2.php/apps/spreed/api/v3/signaling instead, the client fell back to long-polling -- the HPB is not being used, recheck Step 8.

Verify Media Is Flowing Through HPB

Inside a call, open chrome://webrtc-internals (or about:webrtc in Firefox). Look at the ICE candidates for the active connection:

• srflx candidates come from STUN -- normal, used for direct P2P paths.
• relay candidates come from TURN -- these indicate the media is being relayed through coturn.
• The remote IP on the selected candidate pair should be your VPS public IP, not another participant's home IP.

Load Test

For a realistic load test, have 5+ participants join at once. Monitor the server:

# CPU/RAM
htop
Network throughput
sudo apt install -y bmon
bmon
Janus + signaling logs
sudo journalctl -u janus -u signaling -f

A 10-person call should consume roughly 2-4 vCPU and 15-30 Mbps outbound on your VPS. If CPU spikes to 100% or you see packet loss, you have outgrown the current plan -- the CloudCore Professional tier handles 20-30 participants comfortably.

Troubleshooting

Viewing Logs

The three log streams to watch during any call troubleshooting:

# Signaling server
sudo journalctl -u signaling -f
Janus media server
sudo journalctl -u janus -f
coturn (uses its own log file)
sudo tail -f /var/log/turnserver/turnserver.log

For Nextcloud application-side errors, check the Nextcloud log:

sudo tail -f /var/www/nextcloud/data/nextcloud.log

FAQ

Do I need a separate server for the HPB, or can it run on the same VPS as Nextcloud?

For teams under roughly 30 concurrent participants, running everything on a single well-sized VPS is fine and is what most self-hosters do. The HPB components (Janus, coturn, signaling) are lightweight when idle and only consume serious resources during active calls. If you regularly host calls of 50+ people or run recording alongside, split the HPB onto a dedicated VPS with more bandwidth -- the signaling server supports pointing at an external Janus and coturn, so the only thing that changes is the URLs in /etc/signaling/server.conf.

Can I use a hosted TURN service like Twilio instead of running coturn?

Yes, though you give up a core self-hosting benefit. Nextcloud Talk accepts any STUN/TURN server URL in the admin panel, so Twilio Network Traversal, Xirsys, or Cloudflare Calls all work. The tradeoff: TURN relays see the encrypted media stream pass through them, so you are handing that metadata (who called whom, for how long, from what IP) to a third party. Running coturn yourself on the same VPS typically costs nothing extra in bandwidth unless you are on a metered plan, and keeps call routing metadata on infrastructure you control.

How many participants can Nextcloud Talk HPB support?

With a properly configured Janus on a 6 vCPU / 12 GB VPS and a 1 Gbps port, expect 30-50 participants per call reliably, with multiple concurrent calls of 10-20 participants each. The limiting factor is usually outbound bandwidth -- a 50-person HD call can push 500+ Mbps out of the server since each participant receives 49 streams. For larger deployments, scale horizontally: the signaling server can coordinate multiple Janus instances running on different VPSes.

How does this compare to Jitsi Meet or self-hosted BigBlueButton?

Nextcloud Talk is tightly integrated with your Nextcloud user directory, file sharing, and calendar. It is the right choice when you are already running Nextcloud and want calls that feel native to that ecosystem. It handles 30-50 person calls well, has full mobile apps, and supports federation across Nextcloud instances.

Jitsi Meet is purpose-built for video conferencing and scales to 500+ participants in a single call with the right configuration. It has no persistent chat history or file integration, but its call quality and moderator tooling are more mature.

BigBlueButton is optimized for education and webinars -- breakout rooms, whiteboarding, polls, recording with slides. Heavyweight to host and less useful for ad-hoc team meetings.

For teams already on Nextcloud, Talk HPB is almost always the pragmatic choice. If you need massive webinars, pair Nextcloud (for storage, chat, files) with a separate Jitsi instance.

How do I enable call recording?

Call recording requires an additional component: the Talk Recording backend. It runs as a separate Python service that joins calls as an invisible participant and records the video stream to MP4. Install it after the HPB is working, configure it with the same signaling shared secret, and point Nextcloud Talk at its URL in the admin panel. Recording is CPU-intensive -- budget an extra 2-4 vCPU per concurrent recording.

Next Steps

With Nextcloud Talk HPB live, here are practical ways to get more value out of your deployment:

• Install the Talk mobile apps -- The iOS and Android apps automatically negotiate with your HPB, delivering the same call quality you get in the browser. Push notifications keep your team responsive without leaving a browser tab open.

• Enable SIP dial-in -- Deploy the Talk SIP Bridge alongside the HPB to let external callers join meetings via phone. Useful for customer calls or team members without good internet.

• Set up call recording -- Add the recording backend so you can capture meetings, training sessions, and interviews directly to your Nextcloud storage.

• Configure backup and monitoring -- Add the Talk config and TURN/Janus configs to your regular Nextcloud backup routine. Deploy Uptime Kuma to monitor https://talk.yourdomain.com/standalone-signaling/api/v1/welcome so you get alerted if signaling goes down.

• Harden coturn further -- For public-facing Talk instances, enable turns: over TLS on port 5349, rotate the shared secret periodically, and apply denied-peer-ip rules to block coturn from relaying to RFC1918 networks on your LAN.

• Read the upstream documentation -- The authoritative references are nextcloud.com/talk for feature docs and github.com/strukturag/nextcloud-spreed-signaling for signaling server internals and advanced tuning.

Scale Your Team Communication with CloudCore Professional

Hosting Nextcloud Talk with the High Performance Backend takes real CPU, RAM, and bandwidth -- especially once your team grows past 10 regular users. Our CloudCore Professional plan is sized specifically for self-hosted collaboration stacks:

- 6 vCPU cores for Janus SFU under load

- 12 GB RAM for Nextcloud + Talk + signaling stack

- 100 GB NVMe SSD for call recordings and file attachments

- Unmetered 1 Gbps bandwidth for TURN relay traffic

- EU-hosted for GDPR-friendly communication

Launch CloudCore Professional -- Starts at EUR 19.99/month, deploys in under 60 seconds.