Skip to content

GCP auto-managed (BETA)

The plugin can provision and manage a complete Jitsi Meet server in Google Cloud Platform for you, directly from Moodle. You don't set up anything by hand: the plugin creates the VM, installs Jitsi, configures JWT authentication, obtains an SSL certificate and registers the server so it's ready to use.

This is the simplest way to get a fully-featured, production-ready setup. With a GCP auto-managed server you can:

  • Create Jitsi servers on-demand directly from Moodle
  • Automatically configure Jitsi Meet with JWT authentication
  • Manage the server lifecycle (start / stop instances)
  • Use static IP addresses for consistent DNS configuration
  • Provision Let's Encrypt SSL certificates automatically

This feature is in BETA

GCP integration is experimental. Use it in production environments with caution.

Prerequisites

Before using the GCP integration you need:

  1. Google Cloud Platform account

    • An active GCP project with billing enabled
    • The Compute Engine API enabled

  2. A service account with permissions

    • Create a service account in your GCP project
    • Grant it the following roles:
      • Compute Admin (roles/compute.admin) — to create and manage instances
      • Service Account User (roles/iam.serviceAccountUser) — to attach service accounts to instances
    • Download the JSON key file for this service account

  3. A domain name (required)

    • A fully qualified domain name (FQDN) you can point to the VM's IP address
    • Required for JWT authentication and Let's Encrypt SSL certificates
    • Example: jitsi.example.com

Configuration steps

1. Enable the Compute Engine API

In the Google Cloud Console:

  1. Go to APIs & Services → Library
  2. Search for Compute Engine API
  3. Click Enable

2. Create a service account

  1. Go to IAM & Admin → Service Accounts
  2. Click Create Service Account
  3. Name it (e.g. jitsi-moodle-manager)
  4. Grant the roles:
    • Compute Admin
    • Service Account User
  5. Click Create Key and download the JSON file

Keep the key file secure

The JSON key provides full access to your Compute Engine resources. Never commit it to version control.

3. Configure the plugin in Moodle

Navigate to Site administration → Plugins → Activity modules → Jitsi → Google Cloud (GCP) - BETA and fill in:

Setting Description
Project ID Your GCP project ID (e.g. my-project-12345). Find it in the GCP Console dashboard.
Zone The Compute Engine zone where VMs are created (e.g. europe-west1-b). Choose one close to your users. Zones list.
Machine Type VM size (default e2-standard-4). See sizing below.
Base Image OS image (default projects/debian-cloud/global/images/family/debian-12). Debian 12 is recommended; don't change it unless you have a custom Jitsi image.
Network VPC network (default global/networks/default). Use the default unless you have a custom VPC.
Hostname (FQDN) — required The FQDN for your Jitsi server (e.g. jitsi.example.com). Required for JWT and SSL. You must point DNS to the VM's IP, and also create an A record for auth.<your-hostname>.
Let's Encrypt Email — required Email for Let's Encrypt notifications (certificate requests and expiry notices).
Service Account JSON Upload the JSON key file from step 2.

Machine type guidance:

Type Resources Suitable for
e2-standard-2 2 vCPUs, 8 GB RAM small meetings (< 20 participants)
e2-standard-4 4 vCPUs, 16 GB RAM medium meetings (< 50 participants) — recommended
e2-standard-8 8 vCPUs, 32 GB RAM large meetings (> 50 participants)

See VM instance pricing.

4. Firewall rules (automatic)

The plugin automatically creates a firewall rule named mod-jitsi-allow-web:

  • Ports: TCP 80 (HTTP), TCP 443 (HTTPS), UDP 10000 (Jitsi videobridge)
  • Target: instances tagged mod-jitsi-web
  • Source: 0.0.0.0/0 (all internet traffic)

If the plugin lacks permission to create firewall rules, you'll need to create this rule manually in the GCP Console.

Creating a Jitsi server

Once configuration is complete:

  1. Go to Site administration → Plugins → Activity modules → Jitsi → Server management
  2. Click Create server in Google Cloud
  3. The plugin will:
    • Reserve or reuse an available static IP address
    • Create a Compute Engine VM with the specified configuration
    • Install and configure Jitsi Meet automatically
    • Configure JWT authentication with auto-generated credentials
    • Wait for DNS propagation and obtain a Let's Encrypt SSL certificate
    • Register the server in Moodle's server list

A modal shows the progress. Creation typically takes 5–10 minutes, and the startup script will wait up to 15 minutes for DNS propagation.

Configure DNS immediately

The modal displays the static IP address assigned to your VM. As soon as it appears, create these A records in your DNS provider:

  • jitsi.example.com → static IP (main hostname)
  • auth.jitsi.example.com → same static IP (required for JWT)

Use record type A and TTL 300 (recommended for faster propagation). The VM waits for DNS to propagate before completing installation.

How it works

The startup script

The plugin uses a cloud-init / bash startup script that runs on first boot:

  1. DNS waiting phase (0–15 min) — checks whether the configured hostname resolves to the VM's public IP, waiting up to 15 minutes. Without proper DNS, JWT authentication may not work correctly.
  2. Jitsi installation — installs Jitsi Meet from the official repositories, configures Prosody (XMPP server) for JWT authentication using the hostname, and generates a random App ID and Secret for JWT.
  3. SSL certificate — if DNS is configured, requests a Let's Encrypt certificate; if DNS isn't ready, installs a self-signed certificate (browsers will show warnings).
  4. JWT configuration — configures Jicofo and Prosody for token-based authentication, so only users with valid JWT tokens (generated by Moodle) can moderate sessions.
  5. Callback to Moodle — once complete, the VM notifies Moodle with the JWT credentials; Moodle registers the server and makes it available for use.

Static IP address management

  • The plugin automatically reserves a static IP address for each server.
  • If you delete a server, the IP is released back to the pool.
  • When creating new servers, the plugin reuses available static IPs to avoid quota limits.
  • Each static IP incurs a small cost (~$0.01/hour, or ~$7/month while in use).

Managing servers

Created servers appear in the Server Management interface with these options:

  • Edit — change the server name and configuration.
  • Start / Stop — control the VM lifecycle to save costs. Stopped VMs incur only storage costs (much cheaper than running ones); starting a stopped VM takes ~1–2 minutes.
  • Delete — permanently remove the server.

Deleting a server

Deleting removes the VM and releases the static IP. Existing sessions using that server will no longer work.

Cost considerations

Running Jitsi servers in GCP incurs costs.

Compute instance (while running):

Type Approx. cost
e2-standard-2 ~$49/month (8760 h)
e2-standard-4 ~$98/month
e2-standard-8 ~$196/month

Use the Stop feature when the server isn't in use to save costs.

Static IP address:

  • ~$7/month per IP when attached to a running instance
  • ~$9/month per IP when reserved but not in use
  • Delete unused IPs to avoid charges

Storage: ~$0.17/month per 20 GB SSD (default boot disk).

Network egress (outbound traffic from the VM):

  • First 1 GB/month: free
  • After 1 GB: ~$0.12/GB (varies by region)
  • 1-to-1 calls are minimal (peer-to-peer, no server bandwidth); 3+ participants are high because the Jitsi Videobridge retransmits all streams.
  • A 1-hour HD conference with 10 participants can use 5–10 GB of egress.

Egress can be the largest cost

For institutions with frequent large meetings, network egress is often the biggest expense. Consider monitoring actual usage before scaling to many users.

Cost-saving tips:

  • Stop VMs when not in active use (e.g. outside business hours).
  • Delete servers you no longer need.
  • Consider Preemptible VMs for testing (not recommended for production).

Security considerations

  1. JWT authentication — all auto-created servers use JWT by default. Only Moodle can generate valid tokens, so users cannot join or moderate without Moodle-issued credentials.
  2. Service account security — keep the JSON key file secure, never commit it to version control, rotate keys periodically, and use least-privilege (grant only the necessary roles).
  3. Network security — the firewall rule opens ports to the internet (required for Jitsi); Jitsi itself handles authentication via JWT. Consider Cloud Armor for DDoS protection in production.
  4. SSL certificates — always use Let's Encrypt certificates in production. Self-signed certificates show browser warnings; Let's Encrypt certificates auto-renew via certbot.

Recording and AI come included

A GCP auto-managed server provisions a dedicated Jibri recording VM, with recordings saved to Google Cloud Storage and AI features available. See Recording for details.