Documentation

Publishing a service: HTTP and TCP

A VIGIL-MESH mesh keeps its services among its members by default: nothing is reachable from the public internet until you have decided it should be. Publishing means opening a precise door to a single service — an internal web application, an API, a stream — without exposing the rest of the network. This page explains the principle of a publication, the difference between an HTTP publication (with reverse-proxy and automatic certificates) and a TCP publication, and the cases where one or the other is the right fit.

The principle: bring a service out without exposing the infrastructure

Inside the mesh, your machines reach each other through stable addresses and internal names, and none of that is visible from the outside. A publication adds a single public entry point that points at one internal service. Incoming traffic is received by the platform, then relayed to the service through the encrypted mesh. The visitor only sees a URL or a port; they learn nothing about the topology, the other machines or the services that stayed private.

This decoupling is the main benefit: the published service does not need to be exposed directly on the internet, opens no inbound port on its own machine, and remains reachable even if it lives behind a home NAT or on a mobile link. The platform, and it alone, presents a public surface.

One door per service

Each publication targets a single internal service. Whatever is not explicitly published stays unreachable from the outside, with no extra configuration.

No port to open on the service side

The machine hosting the service exposes nothing: it joins the mesh outward. The platform is what receives the public traffic and relays it.

The topology stays private

Internal addresses, machine names, unpublished services: nothing is revealed to the visitor. A publication only leaks what you have chosen to show.

HTTP publication: reverse-proxy and automatic certificates

HTTP publication suits services that speak the web: an internal application, a dashboard, a REST API. The platform acts as a reverse-proxy: it terminates the TLS connection on the public side, then carries the request to the internal service through the mesh. The service receives an ordinary HTTP request and needs to know nothing about the public encryption or the domain through which it is reached.

1
Designate the internal service to publishThe mesh machine and the port on which the web application to expose is listening. The service keeps running exactly as before, unmodified.
2
Choose the public nameThe domain or subdomain through which visitors will reach the service. Its management (ownership, DNS, activation) is described in the domains documentation, at /en/docs/plateforme-domaines.
3
Let the platform obtain the certificateThe TLS certificate is requested and renewed automatically for the public name. You have no file to install and no expiry date to watch.
4
The reverse-proxy relays to the serviceOnce the name is active, incoming traffic is terminated on the public side then carried to the internal service by the encrypted mesh.

TCP publication

Not every service speaks HTTP. For a database, an SSH service, a business protocol or anything that is not web-based, TCP publication exposes a raw transport port. The platform accepts inbound connections on that port and relays them to the internal service, without interpreting the content of the stream and therefore without terminating any application-level TLS.

Aspect	HTTP publication	TCP publication
Nature of the service	Web application, API, dashboard	Raw TCP stream: database, SSH, business protocol
Public entry point	Domain name	Transport port
TLS terminated by the platform	Yes, with an automatic certificate	No: the stream is relayed as is
End-to-end encryption	Up to the internal application	Up to the published protocol itself

Reserve TCP publication for cases where the web does not apply. For a web application, the HTTP path offers automatic certificates and a better-controlled public surface.

Use cases

Publication answers a recurring need: making a resource that lives inside the mesh reachable from the outside, without relocating that resource or opening up its site. A few typical situations:

Exposing an internal application (business tool, dashboard) to remote users through a domain name, over HTTP with an automatic certificate.
Opening controlled access to a camera stream hosted on a remote site: the details of this scenario are covered in /en/docs/cas-cameras.
Giving a TCP entry point to a non-web service (database, business protocol) hosted behind a NAT, without opening a port on the host machine.
Publishing an API consumed by external partners, while keeping the rest of the infrastructure invisible.

Does publishing open access to the rest of the network?

No. A publication targets a single service. The other machines and services in the mesh stay private: they do not become reachable because a neighboring service is published.

Do I need to open a port on the machine hosting the service?

No. The host machine joins the mesh outward and has no inbound port to open. The platform is what receives the public traffic and relays it to the service.

When should I choose TCP over HTTP?

Choose HTTP whenever the service is web-based: you benefit from the reverse-proxy and automatic certificates. Reserve TCP for protocols that are not HTTP, keeping in mind that the platform then relays the stream without encrypting it itself.