55 lines
1.8 KiB
Plaintext
55 lines
1.8 KiB
Plaintext
{
|
|
# Automatic HTTPS. Caddy asks Let's Encrypt on its own; the host has to be reachable from the
|
|
# internet on 80 or 443 for the challenge, which this VM is.
|
|
#
|
|
# One thing to know before choosing the name. CAA says who may issue, and isti.cnr.it
|
|
# authorises digicert.com and sectigo.com for a plain name, with Let's Encrypt allowed for
|
|
# wildcards only. That is not the obstacle it looks like: CAA is evaluated on the canonical
|
|
# name, so a friendly name that is a CNAME into a zone which does authorise Let's Encrypt is
|
|
# issued without trouble - which is exactly how the institute's own hosts already work.
|
|
# A name pointing straight at an address with an A record, under isti.cnr.it, would be refused.
|
|
#
|
|
# If issuance is ever refused, Caddy's log says so in as many words. The way out is a
|
|
# certificate obtained by hand:
|
|
#
|
|
# auto_https off (in this block)
|
|
# tls /certs/host.pem /certs/host-key.pem (in the site block)
|
|
#
|
|
# and mount /certs read-only. The private key of a name the whole institute trusts does not
|
|
# belong in an image, and even less in one built to run code an agent wrote.
|
|
admin off
|
|
email {$MCP_TLS_CONTACT}
|
|
}
|
|
|
|
{$MCP_SITE_ADDRESS} {
|
|
handle_path /coding-agent/* {
|
|
reverse_proxy coding-agent-mcp:3000 {
|
|
flush_interval -1
|
|
}
|
|
}
|
|
|
|
handle_path /dev-server/* {
|
|
reverse_proxy dev-server-mcp:3000 {
|
|
flush_interval -1
|
|
}
|
|
}
|
|
|
|
handle_path /browser/* {
|
|
reverse_proxy browser-mcp:3000 {
|
|
flush_interval -1
|
|
}
|
|
}
|
|
|
|
handle {
|
|
respond "No MCP server is published at this path" 404
|
|
}
|
|
|
|
# One line per request. This gateway is the only door into a machine that runs code an agent
|
|
# wrote, so it should be able to say who knocked. Caddy redacts Authorization and Cookie in its
|
|
# access log by default, so the token itself is not written down.
|
|
log {
|
|
output stdout
|
|
format json
|
|
}
|
|
}
|