> ## Documentation Index > Fetch the complete documentation index at: https://docs.monk.io/llms.txt > Use this file to discover all available pages before exploring further. # Networking > How traffic reaches your app: the cluster ingress, domains, TLS certificates and service connections A deployed app has two kinds of traffic: requests from the internet to your web-facing services, and connections between your own services. Monk handles the first with an ingress on the cluster and the second with connections declared in your templates. ## The ingress Each cluster can run an ingress, built on Traefik. It serves HTTP and HTTPS on ports 80 and 443 and routes requests to your services. Creating a cluster turns the ingress on. Monk can check it and turn it on again if it was switched off. A web-facing service declares **ingress routes** in its template, for example a route for path prefix `/`. Your coding agent adds these when it configures a cloud or cluster deployment. A service that only publishes a plain port is reachable on the node's IP address and that port, which suits local mode and internal services. If the ingress isn't available at deploy time, Monk reports it and doesn't fall back to plain ports. The routes start working once the ingress is enabled again, without template changes. ## Domains and certificates There are three ways a service can get a name and a certificate. ### Monk-managed domains A cluster node can get a domain managed by Monk, with a certificate issued by the platform. This gives a working HTTPS address before you set up your own domain. If a node's certificate expires or is about to, for example when an image push fails with a certificate error, Monk can request a fresh one. The node keeps its domain, and the registry and ingress restart to serve the new certificate. ### Your own domain on the ingress To serve your own domain, add a certificate to the ingress. Monk opens a form in the [local dashboard](/getting-started/local-dashboard) where you enter one or more domains, each with its own certificate and private key. Traefik picks the right certificate for each request by domain name. The certificate and key go through the form, never through the chat or the tool call. Monk can list the configured domains and can remove the default certificate. ### Your own domain on a node You can also set a custom domain and certificate on a single node, through the same kind of form. Node certificates work alongside the ingress certificate. Point your domain's DNS records at the cluster yourself, or manage them with a DNS package such as Cloudflare, Route 53 or Cloud DNS from [Integrations](https://monk.io/integrations). See [Custom domain](/guides/custom-domain). ``` /monk serve this app on app.example.com ``` ## Connections between services Services talk to each other through **connections** declared in the templates, not hard-coded hostnames. When one runnable connects to another, Monk resolves the target's address on the cluster's overlay network and passes it to the service, usually as an environment variable. Hostnames copied from a Docker Compose file aren't used as-is: your coding agent turns them into Monk connections when it configures the project. Managed services created as entities, such as a cloud database, pass their endpoints and generated secrets to the services that connect to them in the same way. See [Services and data](/concepts/services-and-data). ## Nodes and tags The nodes of a cluster are its peers. Tags on peers decide which workloads run where, for example keeping capsules on a separate pool of nodes. One reserved system tag marks the node that runs Monk's own system workloads, such as Watcher. See [Clusters and clouds](/concepts/clusters-and-clouds). ## Related Serve your app on your own domain Nodes, tags and the registry How certificates and other secrets are handled Configuration your services need This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.