Running on non-standard ports

From canasta

By default, Canasta uses ports 80 (HTTP) and 443 (HTTPS). To use different ports — for example, to run multiple Canasta instances on the same server — the approach depends on whether you are creating a new instance or changing an existing one.

TLS certificates and non-standard ports

When Canasta is configured with a real domain name, Caddy automatically obtains a TLS certificate from Let's Encrypt. This uses the ACME HTTP-01 challenge, which requires Let's Encrypt to connect to port 80 on your server. If you set HTTP_PORT to a non-standard value, the challenge will fail because Let's Encrypt cannot reach Caddy on port 80.

Non-standard ports are therefore intended for local development and testing (e.g., localhost:8443), not for production deployments with automatic TLS. To serve a real domain over HTTPS on non-standard ports, put a shared reverse proxy in front of Canasta — see Behind a shared reverse proxy below.

New instance

Pass an env file with port settings to canasta create. Create a file called custom.env:

HTTP_PORT=8080
HTTPS_PORT=8443
canasta create -i staging -w testwiki -n localhost -e custom.env

Pass --domain-name (-n) as a bare hostname — do not include the port. The port comes from the env file, and the CLI combines them for you. After the instance starts, access the wiki at https://localhost:8443.

Existing instance

Use canasta config set. Multiple settings can be changed in a single command. The HTTPS_PORT side effect automatically updates config/wikis.yaml URLs, MW_SITE_SERVER, and MW_SITE_FQDN to match:

canasta config set HTTP_PORT=8080 HTTPS_PORT=8443

To revert to the default ports (80/443), remove the overrides:

canasta config unset HTTP_PORT HTTPS_PORT

Multiple instances on localhost

Each Docker Compose instance on the same host must use unique ports.

# Default ports (80/443)
canasta create -i production -w mainwiki -n localhost
# Custom ports
canasta create -i staging -w testwiki -n localhost -e custom.env

Access them at https://localhost and https://localhost:8443.

Behind a shared reverse proxy

To serve a real domain over HTTPS on non-standard ports — or to run several TLS-enabled instances on a single host — place a shared reverse proxy (such as Caddy or nginx) in front of all instances. The reverse proxy holds ports 80/443 and obtains the certificates; each Canasta instance serves plain HTTP on its own internal port and lets the proxy terminate TLS.

Disable the instance's own ACME and set its internal HTTP port in custom.env:

CADDY_AUTO_HTTPS=off
HTTP_PORT=8080
canasta create -i staging -w testwiki -n example.com -e custom.env

Then point MediaWiki at the public HTTPS address the proxy serves. This step is required: canasta create derives the server URL from the instance's own internal port and scheme, not from the proxy's public URL.

canasta config set MW_SITE_SERVER=https://example.com --id staging

Finally, configure the reverse proxy to forward traffic for example.com to the instance's internal HTTP port (8080 in the example above).

Kubernetes

On Kubernetes, multiple instances on the same cluster typically share the standard ports (80/443) and are differentiated by hostname via the cluster's ingress controller, rather than by port. See Ingress and TLS.