What is it?
Securely connect Claude to MCP servers running in your private network without opening inbound ports or exposing services to the internet. MCP Tunnels is currently in private beta and relies on Cloudflare’s Tunnel service.
How it works
MCP Tunnels create a connection between Claude and your internal MCP servers that is encrypted in transit with multiple layers of security.
When Claude needs to reach an MCP server in your private network, the request travels through a secure tunnel. You deploy two components on your side:
cloudflared (Cloudflare's tunnel agent)
MCP Gateway (provided by Anthropic)
Cloudflared initiates an outbound-only connection to Cloudflare's edge. No inbound ports need to be opened in your firewall. The MCP Gateway terminates an inner TLS layer, validates upstream IPs to prevent SSRF, and routes each request to the correct MCP server based on subdomain.
The connection is secured with three independent layers: outer mTLS between Anthropic and Cloudflare (with IP validation), inner TLS that encrypts payloads end-to-end from Anthropic's backend to your gateway (designed so Cloudflare doesn't have access to MCP payloads), and OAuth authentication at the application layer on each MCP server.
What you deploy
cloudflared
Cloudflare's tunnel agent. Initiates outbound-only connections — no inbound ports needed.
MCP Gateway
Anthropic-provided component that terminates inner TLS, validates IPs, and routes requests to your MCP servers.
Key security properties
No inbound ports required. cloudflared initiates outbound connections only — your firewall stays closed.
End-to-end encryption. Traffic is encrypted in transit from Anthropic's backend to your gateway. MCP payloads cannot be read by Cloudflare.
Defense in depth. Multiple authentication layers: mTLS, inner TLS, and OAuth at the application layer.
SSRF protection. The gateway validates upstream IPs to help prevent request forgery attacks.
This guide provides reference deployments via Helm (for Kubernetes) and Docker Compose. You are responsible for adapting them to meet your organization's security requirements.
Shared responsibility
Keeping this system secure is a shared responsibility between Anthropic and your organization.
Anthropic is responsible for:
Ensuring only Anthropic can access tunnels
Validating your CA certificate before connecting to your gateway
Ensuring Claude only sends requests to tunnels owned by your organization
You are responsible for:
Following the guidance in this document and any subsequent guidance
Securing the tunnel token and TLS private keys
Configuring your MCP servers to use OAuth authentication as described in the MCP spec
Restricting access to your gateway hosts and MCP servers to appropriate personnel
Notifying Anthropic if you suspect the system has been compromised (see Responding to a suspected breach)
⚠️ Credential risk. If an attacker obtains your tunnel token and either one of your TLS private keys, they could impersonate your gateway and read MCP request payloads, including OAuth tokens. Protect these credentials according to your organization's security requirements—including file permissions, encryption at rest, and secrets management.
Prerequisites
A deployment target — a Kubernetes cluster (for Helm) or a VM with Docker and Docker Compose.
An Anthropic API token for the Tunnels API — generate one from claude.ai → Organization Settings → Connectors → Tunnels API. Setup uses this token to provision the tunnel and register your CA certificate. The gateway does not need it at runtime. Revoke it once you finish setup.
Network access — outbound connectivity per the table below.
MCP servers — one or more MCP servers running in your private network that the gateway can reach.
Network requirements
Component | Destination | Purpose |
Setup (one-time) |
(port 443) | Tunnel provisioning |
cloudflared | Cloudflare edge, port 7844 TCP/UDP ( | Tunnel connection |
MCP Gateway | Your MCP servers | Upstream traffic |
See Cloudflare's tunnel firewall documentation for the authoritative IP list. Helm users can enforce this egress restriction by enabling the chart's networkPolicy value.
Choose your deployment method
MCP Tunnels can be deployed via Helm (Kubernetes) or Docker Compose. Choose the method that fits your infrastructure.
⎈ Helm / Kubernetes
Recommended for most customers. Automates tunnel provisioning and certificate renewal. Stores credentials as Secrets.
🐳 Docker Compose
For single-host or VM deployments.
Helm / Kubernetes deployment
Helm / Kubernetes deployment
1. Fetch the chart values
Download the default values file. It includes comments explaining each field.
Shell
helm show values \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 > values.yaml
2. Configure your routes
Edit values.yaml and add at least one route under gateway.config.routes. Each route maps a subdomain prefix to an upstream MCP server URL.
3. Review the rendered manifests
Render the chart with a placeholder token to inspect the Kubernetes resources before installing. The chart requires api.token to render, but helm template does not call the API.
Shell
helm template mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 \
-n mcp-tunnel \
-f values.yaml \
--set api.token=placeholder > rendered.yaml
Review rendered.yaml according to your organization's practices for vetting third-party manifests.
4. Install the chart
Store your API token in an environment variable, then install. A dedicated namespace is recommended for isolation.
Shell
# Paste your API token (input is hidden)
read -rs API_TOKEN && export API_TOKEN
helm install mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 \
--namespace mcp-tunnel --create-namespace \
-f values.yaml \
--set api.token="$API_TOKEN"
⚠️ Important: Revoke the API token once install completes. Passing the token via --set keeps it out of your values file, but Helm still records it in the release history (sh.helm.release.v1.* Secrets). Kubernetes Secrets are not encrypted at rest by default, so the token remains recoverable from the cluster until you revoke it.
5. Retrieve your tunnel domain
The setup Job writes the tunnel domain to a Secret. You'll need this to configure MCP servers in Claude.
Shell
kubectl get secret mcp-tunnel -n mcp-tunnel \
-o jsonpath='{.data.tunnel-domain}' | base64 -d
Once the tunnel is up and running, connect to Claude.
Optional: Enable NetworkPolicy
Set networkPolicy.enabled: true in your values file to restrict the tunnel pod's egress at the network level. Configure networkPolicy.mcpServers with pod label selectors or CIDR ranges for your upstream MCP servers. The policy already includes egress rules for cloudflared to reach Cloudflare's edge. Your cluster's CNI must support NetworkPolicy—see the values file for an example.
Optional: Gateway configuration
Fields under gateway.config.* are passed through to the gateway's config file. See Appendix: Gateway configuration for the full list. Common adjustments include upstream.allowed_ips, log_level, and upstream.tls for https:// routes. To mount additional files the config references (such as a CA bundle for upstream.tls.ca_file), use gateway.extraVolumes and gateway.extraVolumeMounts.
Upgrades
Always specify --version on helm upgrade. Without it, Helm pulls the latest chart version from the registry, which may not be what you reviewed.
For config changes (routes, replicas, NetworkPolicy, etc.), no API token is needed. The setup Job is skipped on upgrades unless you pass api.token:
Shell
helm upgrade mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 \
-n mcp-tunnel \
-f values.yaml
For tunnel token rotation, increment tunnel.tokenVersion in your values file, generate a fresh API token, and upgrade:
Shell
# Paste your API token (input is hidden)
read -rs API_TOKEN && export API_TOKEN
helm upgrade mcp-tunnel \
oci://us-docker.pkg.dev/anthropic-public-registry/charts/mcp-tunnel \
--version 0.1.0 \
-n mcp-tunnel \
-f values.yaml \
--set api.token="$API_TOKEN"
Revoke the API token once the upgrade completes.
Maintain a complete values file rather than relying on --reuse-values. Helm deep-merges map fields, so deleting a route with --reuse-values silently fails.
Using helm template with kubectl or kustomize
If you prefer to render manifests and apply them yourself (via kubectl apply or kustomize overlays), use external mode (setup.enabled: false). Provision the tunnel separately (see Appendix: Tunnels API) and supply the credentials as pre-created Secrets referenced by external.tunnelTokenSecretName and external.serverCertSecretName. If you issue your own certificates rather than using the setup binary, see Appendix: Certificate requirements.
Docker compose deployment
Docker compose deployment
1. Prepare the deployment directory
Shell
mkdir -p mcp-gateway/{config,tunnel-data}
cd mcp-gateway
sudo chown 65532:65532 tunnel-dataThe chown lets the container (which runs as UID 65532) write to the bind-mounted directory.
2. Create docker-compose.yaml
YAML
services:
# One-time provisioning. Run with: docker compose run --rm setup
setup:
image: us-docker.pkg.dev/anthropic-public-registry/images/mcp-gateway@sha256:62ddf0897778c80997ca789189a8a0bd63df241659d661ff9d5b0e06b5ee1dcd
entrypoint: ["/setup"]
command:
- init
- --api-url=https://api.anthropic.com
- --output=dir:/data
- --token-version=1
environment:
- API_TOKEN
volumes:
- ./tunnel-data:/data
user: "65532:65532"
read_only: true
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
profiles: ["setup"]
cloudflared:
# Verify digest at https://hub.docker.com/r/cloudflare/cloudflared/tags
image: cloudflare/cloudflared@sha256:6b599ca3e974349ead3286d178da61d291961182ec3fe9c505e1dd02c8ac31b0
command: tunnel --no-autoupdate --config /etc/cloudflared/config.yaml run
environment:
- TUNNEL_TOKEN
volumes:
- ./config/cloudflared-config.yaml:/etc/cloudflared/config.yaml:ro
restart: unless-stopped
user: "65532:65532"
read_only: true
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
stop_grace_period: 30s
logging:
options:
max-size: "10m"
max-file: "3"
mcp-gateway:
image: us-docker.pkg.dev/anthropic-public-registry/images/mcp-gateway@sha256:62ddf0897778c80997ca789189a8a0bd63df241659d661ff9d5b0e06b5ee1dcd
volumes:
- ./config/mcp-gateway.yaml:/etc/mcp-gateway/config.yaml:ro
- ./tunnel-data:/data:ro
restart: unless-stopped
user: "65532:65532"
read_only: true
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
# Should match shutdown_timeout in mcp-gateway config
stop_grace_period: 30s
logging:
options:
max-size: "10m"
max-file: "3"
Security measures: non-root execution (UID 65532), read-only filesystem, no privilege escalation, all Linux capabilities dropped, image pinning by SHA256 digest.
3. Provision the tunnel
Shell
# Paste your API token (input is hidden)
read -rs API_TOKEN && export API_TOKEN
docker compose run --rm setup
The setup command creates a tunnel via the Tunnels API, generates a CA and server certificate, registers the CA with Anthropic, and writes all outputs to ./tunnel-data/.
Retrieve your tunnel domain for the next step:
Shell
sudo cat tunnel-data/tunnel-domain
⚠️ Important: Revoke the API token before proceeding.
4. Configure the gateway
Create config/mcp-gateway.yaml:
YAML
listen_addr: ":8080"
log_level: info
shutdown_timeout: 30s
# Your tunnel domain from Step 3
tunnel_domain: abcd1234.tunnel.anthropic.com
tls:
cert_file: /data/tls.crt
key_file: /data/tls.key
routes:
# Replace with your actual MCP servers.
# With tunnel_domain set, keys are subdomain prefixes.
docs: http://docs-mcp.internal:8080
search: http://search-mcp.internal:8080
upstream:
allowed_ips:
- 10.0.0.0/8
See Appendix: Gateway configuration for all available fields.
Create config/cloudflared-config.yaml:
YAML
ingress:
- service: http://mcp-gateway:8080
5. Deploy
Shell
export TUNNEL_TOKEN=$(sudo cat tunnel-data/tunnel-token)
docker compose up -d
docker compose logs -f
Directory structure:
mcp-gateway/
├── docker-compose.yaml
├── config/
│ ├── cloudflared-config.yaml
│ └── mcp-gateway.yaml
└── tunnel-data/
├── tunnel-id
├── tunnel-domain
├── tunnel-token
├── token-version
├── ca.crt
├── ca.key
├── tls.crt
└── tls.key
Consider moving the CA private key and tunnel token to secure storage.
For multi-VM deployments: copy the mcp-gateway/ directory to each host. The same tunnel token and certificates work across all replicas.
Once the tunnel is up and running, connect to Claude.
Certificate renewal (Compose)
The server certificate has a 90-day validity. Renew before expiry:
Shell
docker compose run --rm setup renew-cert --output=dir:/data
The gateway polls the certificate file every 30 seconds and reloads it automatically when it changes. See Appendix: Setup CLI reference for flags that make this command safe to run on a schedule.
Tunnel token rotation (Compose)
Edit docker-compose.yaml to increment --token-version, then re-run setup with a fresh API token:
# Paste your API token (input is hidden)
read -rs API_TOKEN && export API_TOKEN
docker compose run --rm setup
export TUNNEL_TOKEN=$(sudo cat tunnel-data/tunnel-token)
docker compose up -d cloudflared
Revoke the API token once rotation completes.
Connect to Claude
Once the tunnel is running, register your MCP servers in Claude so they're available to users.
1. Add MCP servers
An organization admin navigates to Organization Settings → Connectors → Add → Custom → Web in claude.ai.
Enter each MCP server using its tunnel hostname. For example, docs.abcd1234.tunnel.anthropic.com. The subdomain prefix matches the route key from your gateway config.
2. Users connect
Individual users navigate to Settings → Connectors and click Connect for each MCP server they want to use.
Adding more servers later? Add a new route to your config, apply the change (helm upgrade, or docker compose restart mcp-gateway), and register the new hostname in Claude. No certificate or cloudflared changes needed. The wildcard certificate covers all subdomains.
Security best practices
Require OAuth on your MCP servers. The tunnel and TLS layers protect the transport, but if those are ever compromised, OAuth at the application layer still prevents unauthorized tool invocation. Configure each MCP server to require OAuth authentication as described in the MCP spec.
Enable SSO for your claude.ai organization. Tunnel tokens are generated from the claude.ai Console. With SSO enforced, your identity provider's session controls govern admin sessions.
Restrict
allowed_ips. Use the smallest CIDR ranges that cover your MCP servers.Monitor logs. Set up alerting on warnings, errors, and unusual patterns.
Rotate credentials. Rotate certificates on a regular schedule, or immediately if compromise is suspected.
Keep images updated. Apply gateway updates promptly. Pin images by SHA256 digest.
Limit network access. The gateway and cloudflared should have only the required network access.
Limit MCP server scope. MCP servers should only expose necessary functionality.
Protect credentials at rest. Apply appropriate file permissions, encryption at rest, and secrets management to the
tunnel-data/directory (Compose) or the credentials Secret (Helm).
Responding to a suspected breach
If you suspect your tunnel credentials, TLS keys, or some other aspect of the system has been compromised:
Stop the deployment immediately (
helm uninstallordocker compose down --timeout 0)Remove MCP servers from Claude (Organization Settings → Connectors)
Archive the tunnel via the API (see Teardown, step 3)
Contact Anthropic so they can investigate
Rotate credentials — re-provision a fresh tunnel, rotate OAuth tokens on your MCP servers
Review logs before restoring service
Troubleshooting
IP validation failures
IP validation failures
"IP validation failed" in gateway logs means the upstream resolved to an IP outside allowed_ips. Check the resolved IP:
Shell
dig +short docs-mcp.internal
If the IP is legitimate, update allowed_ips in your gateway config to include the correct CIDR range.
Tunnel not connecting
Tunnel not connecting
Check cloudflared logs for errors. Common causes:
Invalid tunnel token
Firewall blocking outbound port 7844 TCP/UDP to Cloudflare edge
Verify outbound connectivity to Cloudflare's IP ranges: 198.41.192.0/19 and 2606:4700:a0::/44.
UDP buffer size warnings
UDP buffer size warnings
cloudflared may log failed to sufficiently increase receive buffer size. This is a QUIC transport tuning issue — see the quic-go UDP buffer documentation to adjust.
Certificate errors
Certificate errors
If TLS handshake fails, check that:
The server certificate hasn't expired (90-day validity)
The certificate's SAN matches
*.<tunnel-domain>The CA certificate is registered with Anthropic via the API
For Compose, certificate files are readable by UID 65532
Routing OAuth through the tunnel (auth server behind IP allowlist)
Routing OAuth through the tunnel (auth server behind IP allowlist)
Problem: Your auth server sits behind a source IP allowlist. Claude's backend needs to reach it for OAuth discovery, client registration, and token exchange, but you'd rather not whitelist Anthropic's egress IP ranges.
Solution: split-endpoint configuration. Route the backend-to-backend OAuth calls through the tunnel. Keep the browser-facing /authorize endpoint on your existing allowlisted hostname. This works because Claude reads the authorization_endpoint from your discovery metadata and redirects the user's browser there. It doesn't need to reach that URL itself.
Step 1: Add a gateway route for your auth server
YAML — mcp-gateway.yaml
routes:
mcp: http://your-mcp-server:8080
auth: http://your-auth-server:8080
Step 2: Serve split-endpoint discovery metadata
Your auth server's /.well-known/oauth-authorization-server must return:
JSON
{
"issuer": "https://auth.<tunnel-id>.tunnel.anthropic.com",
"authorization_endpoint": "https://<your-allowlisted-host>/authorize",
"token_endpoint": "https://auth.<tunnel-id>.tunnel.anthropic.com/token",
"registration_endpoint": "https://auth.<tunnel-id>.tunnel.anthropic.com/register",
"code_challenge_methods_supported": ["S256"]
}Only authorization_endpoint points at your existing hostname. Everything else uses the tunnel URL.
Step 3: Point your MCP server at the tunnel issuer
Your MCP server's /.well-known/oauth-protected-resource:
JSON
{
"resource": "https://mcp.<tunnel-id>.tunnel.anthropic.com",
"authorization_servers": [
"https://auth.<tunnel-id>.tunnel.anthropic.com"
]
}
Teardown
How to decommission a tunnel when it's no longer needed.
1. Get the Tunnel ID
Helm
TUNNEL_ID=$(kubectl get secret mcp-tunnel -n mcp-tunnel \
-o jsonpath='{.data.tunnel-id}' | base64 -d)
Compose
TUNNEL_ID=$(sudo cat tunnel-data/tunnel-id)
2. Stop the deployment
Helm: helm uninstall mcp-tunnel -n mcp-tunnel (note: the credentials Secret was created by the setup Job, not Helm, so it survives uninstall)
Compose: docker compose down
3. Archive the tunnel
Generate a fresh API token first and revoke it when finished.
Shell
read -rs API_TOKEN && export API_TOKEN
curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/archive" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"
4. Remove stored credentials
Helm: kubectl delete secret mcp-tunnel -n mcp-tunnel
Compose: sudo rm -rf tunnel-data
Getting help
Contact your Anthropic account team for assistance.
Appendix: Gateway configuration
The gateway reads its configuration from a YAML file. In Docker Compose, you write this file directly as config/mcp-gateway.yaml. In Helm, set these fields under gateway.config.* in your values file—the chart manages listen_addr, tls, and tunnel_domain for you.
Field | Description | Default |
| Address and port to listen on | Required |
| Logging verbosity: |
|
| Wait time for in-flight requests during graceful shutdown |
|
| Base domain for prefix route resolution | None |
| Path to TLS certificate | Required |
| Path to TLS private key | Required |
| Hostname (or prefix) to upstream URL mapping | Required |
| CIDR ranges the gateway may connect to | RFC 1918 private ranges |
| Disable IP validation entirely |
|
| CA bundle for validating upstream TLS | None |
| Trust the system CA bundle for upstream TLS |
|
For https:// routes, set at least one of upstream.tls.ca_file or upstream.tls.include_system_cas.
Appendix: Tunnels API
For custom provisioning workflows, you can call the Tunnels API directly. All requests require these headers:
Shell
-H "Authorization: Bearer $API_TOKEN"
-H "anthropic-version: 2023-06-01"
-H "anthropic-beta: mcp-tunnels-2026-02-24"
Create a tunnel:
curl -X POST https://api.anthropic.com/v1/tunnels \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24" \
-H "Content-Type: application/json" \
-d '{}'
List tunnels:
curl https://api.anthropic.com/v1/tunnels \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"
Register a CA certificate:
curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/certificates" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24" \
-H "Content-Type: application/json" \
-d "{\"ca_certificate_pem\": $(jq -Rs . < ca.crt)}"See Appendix: Certificate requirements for what the CA and server certificates must contain.
List CA certificates:
curl "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/certificates" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"
Revoke a CA certificate:
curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/certificates/${CERT_ID}/revoke" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"
Reveal the tunnel token:
curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/reveal_token" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"
Rotate the tunnel token:
curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/rotate_token" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"
Archive a tunnel:
curl -X POST "https://api.anthropic.com/v1/tunnels/${TUNNEL_ID}/archive" \
-H "Authorization: Bearer $API_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: mcp-tunnels-2026-02-24"
Appendix: Certificate requirements
If you use the setup binary (setup init / setup renew-cert), it generates compliant certificates automatically and you can skip this section. These requirements apply if you issue certificates through your own PKI.
CA certificate — upload via POST /v1/tunnels/{id}/certificates. A tunnel holds at most two active CA certificates at a time, allowing rotation without downtime.
PEM-encoded, single certificate, at most 8 KB
BasicConstraintsextension withCA:TRUE, marked criticalSubjectKeyIdentifierextension presentKeyUsageincludeskeyCertSignWithin validity period
RSA 2048-bit or larger, or ECDSA P-256 or larger; SHA-256 or stronger signature
Server certificate — presented by the gateway during the inner TLS handshake. Not uploaded to Anthropic.
Signed directly by a CA registered on the tunnel
AuthorityKeyIdentifierextension present, matching the CA'sSubjectKeyIdentifierSAN includes a DNS name matching
<route>.<tunnel-domain>(a wildcard*.<tunnel-domain>covers all routes)If an
ExtendedKeyUsageextension is present, it includesserverAuthWithin validity period
RSA 2048-bit or larger, or ECDSA P-256 or larger; SHA-256 or stronger signature
Reference: the setup binary generates an ECDSA P-256 CA (5-year validity) and an RSA 4096-bit server certificate with a wildcard SAN (90-day validity).
Appendix: Setup CLI reference
The setup binary runs inside the gateway container via docker compose run --rm setup <subcommand> (Compose) or as a Helm hook and CronJob (Kubernetes).
setup init — creates a tunnel via the Tunnels API, generates a CA and server certificate, registers the CA, and writes all outputs.
Flag | Description | Default |
| Anthropic API base URL. Also read from | required |
| API token with tunnel scope. Also read from | required |
| Output destination: |
|
| Server certificate validity period |
|
| Change-detection string; a new value triggers tunnel token rotation | none |
setup renew-cert — issues a new server certificate signed by the stored CA. No API call required.
Flag | Description | Default |
| Output destination: |
|
| New certificate validity period |
|
| Skip if the existing certificate has more than this long until expiry |
|
Setting --renew-before=720h makes the command a no-op when more than 30 days remain, suitable for running on a schedule.