Server Deployment Guide

• An Oracle Cloud account (oracle.com/cloud/free) — identity verification requires a card, but Always Free resources are never charged.
• An SSH key pair to log into the instance (ssh-keygen locally if you don't have one).
• About 20 minutes.

01.1 — Start instance creation

1. Go to Oracle Cloud Console → Compute → Instances → Create Instance
2. Name it: netcrafter-live

01.2 — Choose the image

1. Under Image, click Change Image
2. Select: Canonical Ubuntu 22.04 (not 20.04, not Minimal, not aarch64)
3. Confirm it shows "Always Free eligible"

01.3 — Choose the shape

Two Always Free shapes are available:

Option A — VM.Standard.A1.Flex (Ampere ARM)

• Up to 4 OCPU / 24 GB RAM free
• Recommended: 2 OCPU / 12 GB RAM
• Better performance for coturn
• Frequently shows "Out of capacity" error — see Troubleshooting below

Option B — VM.Standard.E2.1.Micro (AMD x86)

• 1 OCPU / 1 GB RAM
• Always available — no capacity issues
• Sufficient for NetCrafter Live
• Recommended if A1 is unavailable

To find these shapes:

1. Click Shape series → Specialty and previous generation
2. Look for shapes marked Always Free-eligible
3. Select VM.Standard.A1.Flex OR VM.Standard.E2.1.Micro

01.4 — Configure networking

Do not skip any step:

1. Under Primary VNIC → Virtual cloud network, select Create new virtual cloud network
2. Enter a name: netcrafter-vcn
3. Under Subnet, select Create new public subnet
4. Enter a name: public-subnet
5. Enter CIDR block: 10.0.0.0/24
6. Under Private IPv4 address, select Automatically assign private IPv4 address
7. Under Public IPv4 address, select Automatically assign public IPv4 address

01.4a — Create Internet Gateway and Route Table

After creating your VCN:

1. Go to Networking → Virtual Cloud Networks → netcrafter-vcn
2. In the left menu click Internet Gateways
3. Click Create Internet Gateway
4. Name: netcrafter-igw
5. Compartment: your root compartment
6. Click Create Internet Gateway

Then add the route rule:

1. In the left menu click Route Tables
2. Click Default Route Table for netcrafter-vcn
3. Click Add Route Rules
4. Fill in: Target Type: Internet Gateway; Destination CIDR Block: 0.0.0.0/0; Target Internet Gateway: netcrafter-igw
5. Click Add Route Rules

Without this route rule, outbound traffic from your instance cannot reach the internet and inbound connections will time out.

01.5 — Add SSH keys

1. Under Add SSH keys, select Generate a key pair for me
2. Click Download private key — saves as ssh-key-YYYY-MM-DD.key
3. Click Download public key — saves as ssh-key-YYYY-MM-DD.key.pub
4. Store both files safely: C:\Users\YourName\.ssh\

The public key field will be automatically populated after downloading.

Open required ports in the Security List

While you have the Security List open, add ingress rules for coturn:

Go to: Networking → Virtual Cloud Networks → netcrafter-vcn → public-subnet → Security Lists → Default Security List → Add Ingress Rules

01.6 — Boot volume

Leave all boot volume settings as default: do not check custom boot volume size, do not check in-transit encryption, do not attach block volumes.

01.7 — Review and create

Confirm: Image Canonical Ubuntu 22.04; Shape VM.Standard.A1.Flex or VM.Standard.E2.1.Micro; Public IPv4 address Yes; SSH keys present.

Click Create. Wait 1-2 minutes for status to change from Provisioning to Running. Note the Public IP address shown on the instance details page.

Troubleshooting — Out of Capacity

If you see:

"Out of capacity for shape VM.Standard.A1.Flex in availability domain AD-1"

Try these in order:

1. Change availability domain — try AD-2 or AD-3 instead of AD-1
2. Remove fault domain — set to "Let Oracle choose the best fault domain"
3. Switch to E2.1.Micro — under Shape, select Specialty and previous generation, then pick VM.Standard.E2.1.Micro. Always available and sufficient for NetCrafter Live.
4. Retry later — Oracle releases A1 capacity randomly. Try again in 30-60 minutes or the following morning.

Troubleshooting — SSH Connection Timed Out

SSH times out even though port 22 is in the Security List. This is almost always caused by a missing Internet Gateway or route rule.

Check this in order:

1. Go to Networking → Virtual Cloud Networks → netcrafter-vcn
2. Click Internet Gateways in the left menu — if NONE exists, create one named netcrafter-igw (see Section 01.4a)
3. Click Route Tables → Default Route Table — confirm there is a rule with Destination 0.0.0.0/0, Target Internet Gateway; if missing, add it with those values

Sections 04-09 below install and configure coturn and the rendezvous service by hand, one SSH command at a time — that's still exactly what happens, and it's worth reading if you want to understand or customize any of it. But you don't have to type it all in yourself: install-live-server.sh, shipped alongside the other server files, runs the entire sequence in one pass and ends with both services running, enabled on boot, and verified.

It does not change the self-hosted architecture — you're still running your own server, on your own instance. It only automates the setup.

03.1 — Copy the files onto the instance

Three files ship together at Assets/PivecLabs/NetCrafterLive/ServerTools/:

install-live-server.sh
rendezvous_server.py
netcrafter-live-rendezvous.service

Copy all three (adjust the source path to wherever your Unity project lives):

scp -i /path/to/your_private_key \
  "Assets/PivecLabs/NetCrafterLive/ServerTools/install-live-server.sh" \
  "Assets/PivecLabs/NetCrafterLive/ServerTools/rendezvous_server.py" \
  "Assets/PivecLabs/NetCrafterLive/ServerTools/netcrafter-live-rendezvous.service" \
  ubuntu@<PUBLIC_IP>:~/

03.2 — Run it

sudo bash ~/install-live-server.sh

With no flags, it prompts for each value it can't detect itself (public/private IP are auto-detected via cloud metadata and ifconfig.me/interface routing, with a chance to confirm or override; the TURN shared secret defaults to a freshly generated random one). Pass -y/--yes to accept every detected/default value without prompting, or supply any value directly as a flag — --public-ip, --private-ip, --realm, --turn-username, --shared-secret, --rendezvous-port, --min-port, --max-port. Run --help for the full list.

Want to see exactly what it would do first, with no root and no changes to the real system? bash install-live-server.sh --dry-run writes every generated file (turnserver.conf, the systemd unit, etc.) under a local ./netcrafter-live-dry-run/ folder and echoes every privileged command instead of running it.

Step by step, a real (non-dry-run) run:

1. Installs coturn via apt.
2. Detects (or accepts as flags) public IP, private IP, realm, TURN username, and TURN shared secret — confirming each with you unless --yes is passed.
3. Writes /etc/turnserver.conf from those values — matching Section 06 exactly, unless a real existing config is already there, in which case it only appends this product's user= line. Also creates /var/log/turnserver/ and sets its ownership so coturn can actually write its own log file.
4. Enables and starts the coturn systemd service.
5. Installs rendezvous_server.py to /opt/netcrafter-live/ and the systemd unit to /etc/systemd/system/, creating the netcrafter-live system user and /var/lib/netcrafter-live-rendezvous data directory.
6. Enables and starts the rendezvous systemd service.
7. Opens both services' ports via iptables (+ netfilter-persistent save), then prints an explicit reminder about your cloud provider's separate network-level firewall — iptables cannot reach or open that layer.
8. Verifies: curls the rendezvous service's endpoints (including a full host/join/peers round trip), checks coturn's systemd status, and runs a local turnutils_uclient credential smoke test if available — then prints a plain summary of what's running and the exact values to paste into Unity's Relay Settings.

That final summary looks like this (values will differ per instance):

========================================================
NetCrafter Live server setup complete.

Running:
  coturn                       : UDP/TCP 3478, relay ports 49160-49200
  netcrafter-live-rendezvous  : TCP 8788

Paste these into Unity -> NetCrafter Live window -> Relay Settings:

  Relay Host       : 192.0.2.10
  Relay Port       : 3478
  Rendezvous URL   : http://192.0.2.10:8788
  TURN Username    : netcrafter-live
  Shared Secret    : <your generated or provided secret>

  NOTE: Rendezvous URL includes the http:// prefix, shown above -- Relay Host
  does NOT take one (TURN doesn't use a scheme). Paste Rendezvous URL exactly
  as printed, scheme included.

IMPORTANT -- cloud firewall (this script cannot reach this):
  This looks like an Oracle Cloud instance. The iptables rules above only
  cover this machine's own firewall -- Oracle's Security List is a SEPARATE
  network-level firewall that also must allow this traffic in, and this
  script has no way to reach or modify it. Open it yourself:
    Console -> Networking -> Virtual Cloud Networks -> your VCN ->
    Security Lists -> Add Ingress Rules:
      0.0.0.0/0  UDP+TCP  3478              TURN/STUN
      0.0.0.0/0  UDP      49160-49200       Relay ports
      0.0.0.0/0  TCP      8788             Rendezvous service
========================================================

A copy of the credential values is also saved to /root/netcrafter-live-credentials.txt (mode 600).

Safe to re-run, and safe to run alongside another NetCrafter product on the same box: useradd tolerates an existing user, and systemctl enable --now/restart are idempotent. turnserver.conf is never blindly overwritten — the script only writes a fresh file when none of the markers of a real existing config (an actual uncommented lt-cred-mech or user= line) are present. A real existing config, whether from this product's own earlier run, another NetCrafter product's coturn setup, or one you configured by hand, is left alone; only this product's own user= line gets appended to it.

Oracle Cloud has two firewall layers, and both must allow the traffic — this is the most common thing people miss. (The rendezvous service gets its own port later, in Section 09 — same two-layer gotcha applies there too.)

(a) Security List (cloud-level, stateless)

Console → Networking → Virtual Cloud Networks → your VCN → Security Lists → the default security list → Add Ingress Rules:

A narrow relay port range (here, 41 ports) is enough for a handful of concurrent sessions and keeps the open-port surface small — widen it only if you expect many simultaneous sessions.

(b) The instance's own firewall

Oracle's Ubuntu images ship with iptables rules (via netfilter-persistent/oracle-cloud-agent) that block everything not explicitly allowed, on top of the Security List above. Open the same ports locally:

sudo iptables -I INPUT -p udp --dport 3478 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 3478 -j ACCEPT
sudo iptables -I INPUT -p udp --dport 49160:49200 -j ACCEPT

sudo apt install -y iptables-persistent   # if not already installed
sudo netfilter-persistent save

Edit /etc/turnserver.conf:

listening-port=3478
fingerprint
lt-cred-mech
realm=netcrafter.live
user=netcrafter-live:YOUR_SHARED_SECRET_HERE
min-port=49160
max-port=49200
external-ip=<PUBLIC_IP>/<PRIVATE_IP>
no-tls
no-dtls
log-file=/var/log/turnserver/turnserver.log
simple-log
no-multicast-peers

• user=netcrafter-live:YOUR_SHARED_SECRET_HERE — this is the long-term credential: a single username/password pair every peer uses. Pick a real random secret, not a password you use elsewhere.
• external-ip=<PUBLIC_IP>/<PRIVATE_IP> — Oracle instances have a private IP (find it with ip addr show, usually on ens3/eth0) behind a separately NAT'd public IP. This tells coturn to advertise the public IP in relayed-address attributes while binding to the private interface. Without this, peers receive an unreachable private IP and allocation succeeds but relaying silently fails.
• no-tls/no-dtls — keeps the MVP setup simple: coturn's own TURN/STUN control channel runs plain UDP, not TLS/DTLS. This is independent of your actual call/broadcast media, which com.unity.webrtc always encrypts via DTLS-SRTP regardless of this setting — that's mandatory in the WebRTC spec, not something either side can turn off. Fine for a small self-hosted relay; add TLS on the control channel later if you want it too.
• log-file=/var/log/turnserver/turnserver.log — not /var/log/turnserver.log directly. On stock Ubuntu, /var/log itself is owned root:syslog with no write access for other users, and coturn runs as its own dedicated turnserver system user, which can't create a new file there. Create the directory it actually owns before starting coturn:
  bashCopy

  sudo mkdir -p /var/log/turnserver
  sudo chown turnserver:turnserver /var/log/turnserver

  Skip this and coturn silently fails to log anything at all — systemctl status coturn still shows active (running), with no other visible symptom.

The quickest way to verify coturn is working is using a free browser-based TURN checker — no extra software needed.

1. Open webrtc.github.io trickle-ice sample
2. Scroll down to the ICE servers section
3. Remove any existing servers and add yours:

URI:      turn:YOUR_PUBLIC_IP:3478   (e.g. turn:92.5.181.120:3478)
Username: netcrafter-live
Password: <your shared secret from turnserver.conf>

4. Click Add Server
5. Click Gather candidates
6. Wait 10-15 seconds

Join codes need a small lookup service so a host's relayed address can be found by a joiner (and vice versa) — coturn only relays traffic, it doesn't do address-book lookups. This section installs a minimal one on the same instance, listening on its own port.

09.1 — Open its port (both layers)

Pick a port not already used by coturn — this guide uses 8788 (deliberately different from NetCrafter Relay's own default of 8787, so both products' rendezvous services can coexist on one box if you ever run both).

(a) Security List:

(b) The instance's own firewall:

sudo iptables -I INPUT -p tcp --dport 8788 -j ACCEPT
sudo netfilter-persistent save

09.2 — Copy the rendezvous script onto the instance

The service is a single Python 3 file with no pip installs required — Ubuntu 22.04 ships Python 3 by default, and the script only uses the standard library (http.server, sqlite3).

It ships with NetCrafter Live at:

Assets/PivecLabs/NetCrafterLive/ServerTools/rendezvous_server.py
Assets/PivecLabs/NetCrafterLive/ServerTools/netcrafter-live-rendezvous.service

Copy both to the instance:

scp -i /path/to/your_private_key \
  "Assets/PivecLabs/NetCrafterLive/ServerTools/rendezvous_server.py" \
  "Assets/PivecLabs/NetCrafterLive/ServerTools/netcrafter-live-rendezvous.service" \
  ubuntu@<PUBLIC_IP>:~/

09.3 — Install and start it as a systemd service

sudo mkdir -p /opt/netcrafter-live
sudo mv ~/rendezvous_server.py /opt/netcrafter-live/

sudo useradd --system --no-create-home --shell /usr/sbin/nologin netcrafter-live || true
sudo mkdir -p /var/lib/netcrafter-live-rendezvous
sudo chown -R netcrafter-live:netcrafter-live /var/lib/netcrafter-live-rendezvous

sudo mv ~/netcrafter-live-rendezvous.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now netcrafter-live-rendezvous
sudo systemctl status netcrafter-live-rendezvous   # confirm "active (running)"

09.4 — Test it

curl http://<PUBLIC_IP>:8788/

Then confirm the actual join-code contract end to end (this is the same round trip the Server Setup Wizard's own Verify step runs automatically, and a basic proof-of-life smoke test for the rendezvous service's HTTP/database layer independent of which route family — /host /join /peers, /signal/*, or /broadcast/* — your actual components use):

# Simulate a host registering:
curl -X POST http://<PUBLIC_IP>:8788/host -d '{"relayedAddress":"1.2.3.4:5000"}'
# -> {"joinCode": "AB3F9", "userId": 0}

# Simulate a joiner resolving that code (use the joinCode from above):
curl -X POST http://<PUBLIC_IP>:8788/join/AB3F9 -d '{"relayedAddress":"5.6.7.8:6000"}'
# -> {"relayedAddress": "1.2.3.4:5000"}

# Simulate the host polling for peers:
curl http://<PUBLIC_IP>:8788/host/AB3F9/peers
# -> {"peers": ["5.6.7.8:6000"]}

In the NetCrafter Live editor window → Relay Settings:

Rendezvous URL accepts a bare host:port the same way Relay Host does — http:// is filled in automatically at runtime if you leave it off.

Rendezvous URL has no working default — the field is required and ships blank. Leaving it blank fails the join-code flow at runtime with a clear error rather than a silent hang; there is no Pivec Labs-hosted fallback to fall back to.

This is the one, project-wide Relay Settings asset — NetCrafterLiveConnection and NetCrafterLiveBroadcast both read these same five fields directly at runtime via their connectionSettings field. If you ran the Server Setup Wizard (Section 03), it already wrote all five of these for you from a verified deploy — you only need to fill this tab in by hand if you set the server up manually.

• The shared secret lives in the project's Relay Settings asset, which may get committed to source control. Treat it as a low-value credential — not a production secret, and never one reused from elsewhere.
• Anyone with a copy of your project (or its Relay Settings asset specifically) can see this secret and, in principle, allocate through your relay. For a handful of concurrent calls/broadcasts the blast radius is small, but it's worth knowing. A production-grade setup would use time-limited, per-session credentials minted by the rendezvous service instead of one static long-term secret — not something this version implements.
• The rendezvous service has no authentication beyond knowing the join code — anyone who guesses or brute-forces a 5-character code within its ~15 minute lifetime could poll its peer list. This is a low-value target for short-lived codes.
• The rendezvous service's database is a single SQLite file at /var/lib/netcrafter-live-rendezvous/rendezvous.db. Disposable by design — no need to back it up.
• Always Free has an outbound data transfer allowance (10TB/month at time of writing) — keep an eye on it if you expect heavy use.
• Keep the instance patched: sudo apt update && sudo apt upgrade -y periodically.

• Time-limited, per-session TURN credentials — minted by a server-side service instead of the single long-term shared secret used throughout this guide. Would close the gap noted in Section 11's security notes; not implemented in this version.
• TLS/HTTPS for either coturn (control channel) or the rendezvous HTTP service — both run plain UDP/HTTP here. Add TLS yourself if you need encrypted control traffic.
• Scaling beyond a single instance — this guide is sized for a handful of concurrent sessions on one Always Free box, not a matchmaking service for many simultaneous games.
• Provisioning the instance itself, or your cloud provider's network-level firewall — install-live-server.sh (Section 03) automates everything that happens on the instance over SSH. Creating the instance (Section 01) and opening ports in your provider's own console both happen outside SSH, so no script can reach or automate them.
• Video/audio (WebRTC) platform-specific deployment notes — the com.unity.webrtc package dependency install step, platform-specific constraints (Android/iOS permissions and build settings, unsupported platforms), and how to actually verify a video/audio call routes through your TURN relay specifically (as opposed to the data-only round trip in Section 09.4).