{"slug":"tailscale-services","title":"Tailscale Services","tags":["tailscale"],"agent_summary":"Last validated: Feb 2, 2026","trigger_phrases":[],"runnable":false,"markdown":"\r\n# Tailscale Services\r\n\r\nLast validated: Feb 2, 2026\r\n\r\nServices increase reliability, leverage Tailscale's access-controlled routing, and provide a centralized way to manage all internal resources available in your Tailscale network (known as a tailnet). You can focus on maintaining your applications while Tailscale handles the networking complexity.\r\n\r\nTailscale Services let you publish internal resources (like databases or web servers) as named services in your tailnet.\r\n\r\nInstead of connecting to specific devices, users connect to Tailscale Services using stable [MagicDNS](https://tailscale.com/docs/features/magicdns) names while Tailscale automatically routes traffic to available hosts across your infrastructure.\r\n\r\nThis approach decouples your resources from the devices hosting them. For example, a database service remains accessible at the same address even when you migrate it to a different host, add redundant hosts for high availability, or route traffic across regions. You gain built-in traffic steering, granular access control, approval workflows, and the ability to configure different endpoint types for different layers of the networking stack.\r\n\r\n## [Use cases](https://tailscale.com/docs/features/tailscale-services\\#use-cases)\r\n\r\nYou can use Tailscale Services in a variety of scenarios to securely expose internal resources within your tailnet in a way that decouples them from the devices hosting them. For example:\r\n\r\n- **Developer workflows and internal tooling**: Make any internal application or developer resource highly available, horizontally scalable, and secure without complex load balancer configurations.\r\n- **Database connectivity**: Connect securely to database clusters (PostgreSQL, MySQL, RDS) with simplified connection scaling and identity-based access controls.\r\n- **Cluster meshes**: Enable cross-cluster or hybrid-cloud connectivity between any compute resources like EC2 instances, Kubernetes services, or containers.\r\n- **Version-controlled applications**: Generate stable hostnames for frequently updated, version-controlled, or ephemeral resources that persist across deployments.\r\n- **IoT integrations**: Stream device logs and telemetry securely to SIEM or logging services without exposing IoT devices to the public internet.\r\n- **Internal APIs and webhooks**: Expose internal APIs securely without public domains or complex mTLS configurations while maintaining granular access control.\r\n\r\n## [Prerequisites](https://tailscale.com/docs/features/tailscale-services\\#prerequisites)\r\n\r\nTo get started with Tailscale Services, you must have:\r\n\r\n- An active tailnet.\r\n- One or more devices running Tailscale v1.86.0 or later, or an [unstable](https://tailscale.com/docs/install/unstable) v1.87.x release.\r\n- [Owner, Admin, or Network admin](https://tailscale.com/docs/reference/user-roles) account permissions.\r\n- An internal resource running on a tailnet device that you want to expose as a Tailscale Service. The device hosting the resource must use a [tag-based](https://tailscale.com/docs/features/tags) identity.\r\n\r\n## [Get started](https://tailscale.com/docs/features/tailscale-services\\#get-started)\r\n\r\nTo get started with Tailscale Services, you need to define a Service through the admin console, configure an endpoint on a tailnet device (the host), then advertise the endpoint.\r\n\r\n### [Step 1: Define a Tailscale Service](https://tailscale.com/docs/features/tailscale-services\\#step-1-define-a-tailscale-service)\r\n\r\nYou define a Tailscale Service using the admin console. Each Tailscale Service consists of a MagicDNS name, a TailVIP (Tailscale Virtual IP address), a resource definition, and one or more back-end hosts.\r\n\r\n1. Open the [Services](https://login.tailscale.com/admin/services) page of the admin console.\r\n2. Select **Advertise**, and then select **Define a Service**.\r\n3. Within the **Define a Service** dialog, provide a name and description for your Service.\r\n4. Choose a port or set of endpoints your Service will advertise, including the `tcp:` transport protocol prefix (for example, `tcp:443`). Currently, TCP is the only supported transport protocol. Alternatively, enter `do-not-validate` to skip endpoint validation.\r\n5. (Optional) Provide the Service with an identity by adding one or more [tags](https://tailscale.com/docs/features/tags).\r\n6. Select **Add service**.\r\n\r\nYou have now defined the Service interface. Next, you need to configure a tailnet device as a Service host.\r\n\r\n### [Step 2: Configure a Service host](https://tailscale.com/docs/features/tailscale-services\\#step-2-configure-a-service-host)\r\n\r\nA Service host is a Tailscale device that runs the Tailscale client and advertises one or more endpoints for a specific Tailscale Service. The host handles incoming connections to the Service and routes them to the appropriate resource. Hosts can advertise both local and remote resources.\r\n\r\nAny device you want to use as a Service host must use a [tag-based identity](https://tailscale.com/docs/features/tags). You cannot use a device authenticated with a user account as a Service host.\r\n\r\nMake sure to start the resource on a tailnet device that you want to expose as a Tailscale Service. This resource can be a web server, database, or any other service that you want to make available through Tailscale.\r\n\r\nFor example, you might start a basic web server using Node.js and the [`http-server` package](https://www.npmjs.com/package/http-server) that listens on port `8080`:\r\n\r\n```shell\r\n# Install globally\r\nnpm install -g http-server\r\n\r\n# Then start a basic web server\r\nhttp-server -p 8080\r\n```\r\n\r\nThis example starts a basic web server that serves static files from the current directory on port `8080`.\r\n\r\nAfter you have your resource running and listening for connections, you can configure it as a Service host.\r\n\r\nYou can configure a Service host using either the `tailscale serve` CLI command or using a [Service configuration file](https://tailscale.com/docs/reference/tailscale-services-configuration-file).\r\n\r\nTailscale recommends using the CLI method because it automatically handles both configuration and advertisement, while the configuration file method gives you control over these as separate steps.\r\n\r\n1. Run the `tailscale serve` command with the `--service` flag followed by the service name, the protocol, the port number, and the destination:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve --service=svc:web-server --https=443 127.0.0.1:8080\r\n```\r\n\r\n\r\n\r\nThe command returns output similar to the following:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\nThis machine is configured as a service host for `svc:web-server`, but approval from an admin is required. Once approved, it will be available in your Tailnet as:\r\n\r\nhttp://web-server..ts.net:443/\r\n|-- proxy http://127.0.0.1:8080\r\n```\r\n\r\n\r\n\r\n\r\n\r\nWhen you configure and advertise an endpoint using the `tailscale serve` CLI command, it automatically uses background mode (which you would normally need to use the `--bg` flag for when using the `tailscale serve` command).\r\n\r\n\r\n\r\nThis command configures and automatically advertises an endpoint for the resource. When you use the `tailscale serve` command with the HTTPS protocol, Tailscale automatically provisions a TLS certificate for your unique tailnet DNS name.\r\n\r\n2. Run the `tailscale serve status` command to verify your configuration:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve status --json\r\n```\r\n\r\n\r\nTo use [regional routing](https://tailscale.com/docs/how-to/set-up-high-availability#regional-routing)'s in-region load balancing with Tailscale Services, you will need to enable it on your tailnet.\r\n\r\n### [Step 3: Approve a Service host](https://tailscale.com/docs/features/tailscale-services\\#step-3-approve-a-service-host)\r\n\r\nIf your tailnet has [auto-approval](https://tailscale.com/docs/reference/syntax/policy-file#autoapprovers) policies set up for the Service, the host is automatically approved. If not, an [Admin, Network admin, or Owner](https://tailscale.com/docs/reference/user-roles) must approve the host before it becomes active.\r\n\r\n1. Open the [Services](https://login.tailscale.com/admin/services) page of the admin console.\r\n2. Select the name of the Service you created earlier.\r\n3. Locate the pending advertisements in the **Service hosts** section.\r\n4. Select **Approve**.\r\n\r\nAfter approval, the host becomes active and starts handling traffic for the Tailscale Service. Users in the tailnet can now connect to the Service using its MagicDNS name or IP addresses (provided they have the necessary access permissions).\r\n\r\n### [Step 4: Access Tailscale Services from other devices](https://tailscale.com/docs/features/tailscale-services\\#step-4-access-tailscale-services-from-other-devices)\r\n\r\nAfter you configure and approve a Tailscale Service, you need to ensure that other devices in your tailnet can discover and use the routes to the advertised resources.\r\n\r\nTailscale clients version 1.94 and later no longer require enabling `accept-routes` to use Tailscale Services. This lets all clients leverage Tailscale Services by default while simultaneously not enabling `accept-routes` which can lead to route clashes.\r\n\r\nLinux devices running Tailscale version 1.93 or earlier don't discover new routes to Tailscale Services by default. You must explicitly enable accepting routes using the `--accept-routes` flag with the [`tailscale set`](https://tailscale.com/docs/reference/tailscale-cli#set) command:\r\n\r\n```shell\r\nsudo tailscale set --accept-routes\r\n```\r\n\r\n## [Common scenarios](https://tailscale.com/docs/features/tailscale-services\\#common-scenarios)\r\n\r\nThis section covers common scenarios for managing Tailscale Service hosts, including draining a host, removing a host configuration, and updating a Service host configuration.\r\n\r\n### [Drain a host](https://tailscale.com/docs/features/tailscale-services\\#drain-a-host)\r\n\r\nWhen you need to take a Service host offline, you should first drain the host. Draining a host stops it from accepting new incoming connections while letting existing connections to close gracefully.\r\n\r\nUse the `tailscale serve drain` command to stop the host from advertising itself for a service (`svc:`):\r\n\r\n```shell\r\ntailscale serve drain svc:\r\n```\r\n\r\nAfter you run the `tailscale serve drain` command, all associated endpoints on the host stop accepting new incoming connections. However, any ongoing connections remain alive until they close normally.\r\n\r\nAfter all connections close gracefully, you can safely remove all relevant endpoint configurations.\r\n\r\n### [Remove a host configuration](https://tailscale.com/docs/features/tailscale-services\\#remove-a-host-configuration)\r\n\r\nDo not remove an endpoint configuration before draining it. Doing so abruptly ends all connections to the advertised resource.\r\n\r\nAfter draining the endpoint for a resource, you can remove its configuration using one of three ways: remove a specific endpoint (for a single `protocol:port` endpoint mapping), remove the entire host configuration, or reset the configuration file. The best method depends on how much of the configuration file you want to preserve.\r\n\r\nYou can check your Service configuration file at any point using the `tailscale serve status` command.\r\n\r\n```shell\r\ntailscale serve status -json\r\n```\r\n\r\n#### [Remove an endpoint](https://tailscale.com/docs/features/tailscale-services\\#remove-an-endpoint)\r\n\r\nIf you configured multiple endpoints for a single resource using different port numbers or protocols, you can use the `off` argument to remove only a specific endpoint mapping. To remove a specific endpoint mapping for a resource for a specific port number, re-run the original `tailscale serve` command (that you used to configure the endpoint) with the `off` argument. You must run the command with the same values and flags as you did to set up the endpoint.\r\n\r\n```shell\r\ntailscale serve --service:\"svc:\" --https: off\r\n```\r\n\r\nAdding the `off` argument at the end of the command you used to advertise the endpoint with the same flag removes the endpoint configured for a port. For example, have an endpoint for `web-server` on HTTPS port `443` and an endpoint for `web-server` on HTTP ports `80` and `3000` and you need to remove the endpoint for HTTPS port `443`:\r\n\r\n1. Run this command to disable its configuration for only HTTPS port `443`:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve --service=\"svc:web-server\" --https=443 off\r\n```\r\n\r\n2. Then, re-advertise with only HTTP port `80`:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve advertise svc:web-server\r\n```\r\n\r\n\r\nHere's a more complete example of removing an endpoint:\r\n\r\n```shell\r\n# Run tailscale up <...>\r\n# Set up a few L7 endpoints:\r\n\r\ntailscale serve --service=\"svc:web-server\" --https=443 8080\r\ntailscale serve --service=\"svc:web-server\" --https=443 --set-path /mt2 8081\r\ntailscale serve --service=\"svc:web-server\" --http=80 3000\r\n\r\n# When you want to modify config, drain it first.\r\n\r\ntailscale serve drain svc:web-server\r\n\r\n# Wait until all connections close.\r\n\r\n# To only remove the endpoint configuration for the /mt2 path on port 443:\r\n\r\ntailscale serve --service=\"svc:web-server\" --https=443 --set-path /mt2 off\r\n\r\n# Then, advertise it again and it will only create one endpoint on HTTPS port 443\r\n\r\ntailscale serve advertise svc:web-server\r\n\r\n# To remove the endpoint configuration for for HTTPS port 443:\r\n\r\ntailscale serve --service:\"svc:web-server\" --https=443 off\r\n# You will see a prompt asking you to confirm\r\n# After you confirm, it removes all configured endpoints on port 443 but preserves other port configured for the same service resource.\r\n# Advertise the service again without the removed HTTPS port:\r\n\r\ntailscale serve advertise svc:web-server\r\n```\r\n\r\n#### [Remove all endpoint mappings for a Service](https://tailscale.com/docs/features/tailscale-services\\#remove-all-endpoint-mappings-for-a-service)\r\n\r\nTo remove the configuration for a specific Service (which can have one or more endpoints), use the `tailscale serve clear` command.\r\n\r\n```shell\r\ntailscale serve clear svc:\r\n```\r\n\r\nThis removes all endpoint configurations for the Service from service configuration file.\r\n\r\nHere's a more complete example of removing all endpoint configurations for a resource:\r\n\r\n```shell\r\n# Run tailscale up <...>\r\n# Set up a few L7 endpoints:\r\n\r\ntailscale serve --service=\"svc:web-server\" --https=443 8080\r\ntailscale serve --service=\"svc:web-server\" --https=443 --set-path /mt2 8081\r\ntailscale serve --service=\"svc:web-server\" --http=80 3000\r\n\r\n# When you want to modify config, drain it first:\r\n\r\ntailscale serve drain svc:web-server\r\n\r\n# Wait until all connections close.\r\n\r\n# Remove the configuration for svc:web-server:\r\n\r\ntailscale serve clear svc:web-server\r\n```\r\n\r\n#### [Remove all Service configurations](https://tailscale.com/docs/features/tailscale-services\\#remove-all-service-configurations)\r\n\r\nTo reset the entire configuration file (removing all configured Service configurations), use the `tailscale serve reset` command.\r\n\r\n```shell\r\ntailscale serve reset\r\n```\r\n\r\nThis removes all configured endpoints from the Services configuration file.\r\n\r\n### [Update a Service host configuration](https://tailscale.com/docs/features/tailscale-services\\#update-a-service-host-configuration)\r\n\r\nYou can update or modify a host's Service configuration using the `tailscale serve` command or by editing the Service configuration file directly. You should drain the host before modification.\r\n\r\nTo update an endpoint configuration for a given protocol, port, and path, run `tailscale serve` with the same flags. For example, to start an endpoint configured with HTTPS on port `443`:\r\n\r\n1. Run the following command to start an endpoint configured with HTTPS on port `443`:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve --service=\"svc:web-server\" --https=443 https://localhost:443\r\n```\r\n\r\n2. Then, check the configuration with `tailscale serve get-config --all`:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```json\r\n{\r\n \"version\": \"0.0.1\",\r\n \"services\": {\r\n \"svc:web-server\": {\r\n \"endpoints\": {\r\n \"tcp:443\": \"https://localhost:443\"\r\n }\r\n }\r\n }\r\n}\r\n```\r\n\r\n\r\n\r\nTo update the endpoint default path point to local port `8081`:\r\n\r\n3. Run the following command:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve --service=\"svc:web-server\" --https=443 https://localhost:8081\r\n```\r\n\r\n4. Then, check the configuration with `tailscale serve get-config --all`:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```json\r\n{\r\n\"version\": \"0.0.1\",\r\n \"services\": {\r\n \"svc:web-server\": {\r\n \"endpoints\": {\r\n \"tcp:443\": \"https://localhost:8081\"\r\n }\r\n }\r\n }\r\n}\r\n```\r\n\r\n\r\nTo run a different protocol on a port for a local resource, you need to remove the existing endpoint configuration on the port, then add the configuration again. For example, let's say you have an endpoint configured for `my-web-app` with HTTPS on port `443` pointed to a text example, but you need to update it to use HTTP instead of HTTPS:\r\n\r\n1. Remove the endpoint configuration for port `443` by running the following command:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve --service=\"svc:my-web-app\" --https=443 off\r\n```\r\n\r\n2. Then, re-run the `tailscale serve` command to set up the endpoint with HTTP:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve --service=\"svc:my-web-app\" --http=443 http://localhost:8081\r\n```\r\n\r\n\r\n\r\nThe command returns output similar to the following:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\nAvailable within your tailnet:\r\n\r\nhttp://web-server.king-grouse.ts.net:443/\r\n|-- text \"example\"\r\n```\r\n\r\n\r\n### [Configure a Service host using a configuration file](https://tailscale.com/docs/features/tailscale-services\\#configure-a-service-host-using-a-configuration-file)\r\n\r\nTo configure a Service host using the [Service configuration syntax](https://tailscale.com/docs/reference/tailscale-services-configuration-file), you need to create a configuration file (such as `serveconfig.json`) that contains the configuration for the Service host. Note that when you use the configuration file method, you must configure each endpoint mapping, then advertise it as two separate steps.\r\n\r\n1. Create a file named `serveconfig.json` that contains a [`tailscale serve`](https://tailscale.com/docs/reference/tailscale-cli/serve) configuration. This example configures an endpoint for a local web server exposed on port `443` over HTTPS:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```json\r\n{\r\n\"version\": \"0.0.1\",\r\n \"services\": {\r\n \"svc:web-server\": {\r\n \"endpoints\": {\r\n \"tcp:443\": \"https://localhost:443\"\r\n }\r\n }\r\n }\r\n}\r\n```\r\n\r\n2. Use the `tailscale serve set-config` command to apply the configuration file:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve set-config --all serveconfig.json\r\n```\r\n\r\n3. Run the `tailscale serve status` command to verify your configuration:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve get-config --all\r\n```\r\n\r\n4. Advertise the endpoint:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale serve advertise svc:\r\n```\r\n\r\n\r\nYour service host is now handling traffic for your Tailscale Service. You can validate this by running `tailscale status --json | jq '.Self.CapMap.\"service-host\"'` to check the service-host status.\r\n\r\n### [Set up automatic approval](https://tailscale.com/docs/features/tailscale-services\\#set-up-automatic-approval)\r\n\r\nTailscale clients can advertise new Service hosts, but administrators must approve or deny new advertisements (similar to [subnet route approval](https://tailscale.com/docs/features/subnet-routers#enable-subnet-routes-from-the-admin-console)). You can set auto-approval policies to enable certain clients, users, or tags to automatically advertise and approve new hosts for a specific Service or group of Services.\r\n\r\n1. Go to the [Access controls](https://login.tailscale.com/admin/acls) page of the admin console.\r\n\r\n2. Create an auto-approval policy to approve new hosts for an individual Tailscale Service or groups of Tailscale Services (defined by a [tag](https://tailscale.com/docs/features/tags)). The following shows an example:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```json\r\n\"autoApprovers\": {\r\n \"services\": {\r\n \"svc:\": [\"tag:server\"],\r\n \"tag:prod-service\": [\"tag:prod-infra\"]\r\n },\r\n},\r\n```\r\n\r\n\r\n\r\n\r\n\r\nYou can use the [visual policy editor](https://tailscale.com/docs/features/visual-editor) to manage your tailnet policy file. Refer to the [visual editor reference](https://tailscale.com/docs/reference/visual-editor) for guidance on using the visual editor.\r\n\r\n\r\nThe example creates an auto-approval rule for Tailscale clients tagged with the `tag:server` to advertise new Service Proxies, for the Tailscale Service `svc:`. Additionally, it specifies that Tailscale clients with the tag `tag:prod-infra` can advertise new Service Proxies, and automatically receive approval, for Tailscale Services with the tag `tag:prod-service`.\r\n\r\n### [Validate your Service](https://tailscale.com/docs/features/tailscale-services\\#validate-your-service)\r\n\r\nYou can validate that your Service successfully advertised locally, and that it passed validation. To do this, run the following [`tailscale status`](https://tailscale.com/docs/reference/tailscale-cli#status) command and pass its output to the [`jq`](https://jqlang.org/) command-line JSON processor:\r\n\r\n```shell\r\ntailscale status --json | jq '.Self.CapMap.\"service-host\"'\r\n```\r\n\r\nThe `jq` output should show the `service-host` status.\r\n\r\n#### [Configure Service access](https://tailscale.com/docs/features/tailscale-services\\#configure-service-access)\r\n\r\nYou can use a Tailscale Service as a destination in [grant](https://tailscale.com/docs/features/access-control/grants) access control policies.\r\n\r\n1. Go to the [Access controls](https://login.tailscale.com/admin/acls) page of the admin console.\r\n2. Create a grant rule that grants access to your Service. For example, this grant uses `svc:web-server` a destination, on port `443`, with access granted to `\"autogroup:member`.\r\n\r\n```json\r\n{\r\n \"src\": [\"autogroup:member\"],\r\n \"dst\": [\"svc:web-server\"],\r\n \"ip\": [\"443\"],\r\n},\r\n```\r\n\r\nYou can use the [visual policy editor](https://tailscale.com/docs/features/visual-editor) to manage your tailnet policy file. Refer to the [visual editor reference](https://tailscale.com/docs/reference/visual-editor) for guidance on using the visual editor.\r\n\r\nYou can also reference groups of Tailscale Services using a tag you've assigned to each Service. This example grants access to a group of production Services with access to the Service `svc:database`.\r\n\r\n```json\r\n{\r\n \"src\": [\"tag:prod-service\"],\r\n \"dst\": [\"svc:database\"],\r\n \"ip\": [\"5432\"],\r\n},\r\n```\r\n\r\n### [Use access control tests](https://tailscale.com/docs/features/tailscale-services\\#use-access-control-tests)\r\n\r\nTailscale Services are valid `accept` or `deny` destinations in [access control tests](https://tailscale.com/docs/reference/syntax/policy-file#tests).\r\n\r\n### [Check availability](https://tailscale.com/docs/features/tailscale-services\\#check-availability)\r\n\r\nTo check the availability of your Service, you can use the [Services](https://login.tailscale.com/admin/services) page of the admin console.\r\n\r\n1. Open the [Services](https://login.tailscale.com/admin/services) page of the Tailscale admin console.\r\n2. Within the **Advertised** section, you should find your Tailscale Service listed with configured endpoints.\r\n\r\n## [Reference](https://tailscale.com/docs/features/tailscale-services\\#reference)\r\n\r\nThis section provides reference information about Tailscale Services, including endpoint types and service states.\r\n\r\n### [Endpoint types](https://tailscale.com/docs/features/tailscale-services\\#endpoint-types)\r\n\r\nTailscale supports three types of endpoints, each operating at different layers of the networking stack. While the OSI model isn't a perfect representation of modern networking, it provides a useful framework for understanding these distinctions. There are three different types of endpoints: layer 7 (application), layer 4 (transport), and layer 3 (network). This section explains each type, when to use them, and notes about their specific capabilities\r\n\r\n#### [Layer 7 endpoints (application layer)](https://tailscale.com/docs/features/tailscale-services\\#layer-7-endpoints-application-layer)\r\n\r\nLayer 7 (application) endpoints provide the most sophisticated forwarding mechanism by understanding and manipulating application layer protocols. It can inspect, modify, and route traffic based on application-specific content. These types of endpoints work well when you need Tailscale to inject authentication headers in the packets or path-based routing. For example, `/api/*` requests might go to one server while `/static/*` goes to another.\r\n\r\nYou can create a layer 7 endpoint by setting the protocol value to `http` or `https` when using `tailscale serve`.\r\n\r\n- The port number is the port to expose the endpoint on.\r\n- You can use the optional `--set-path` flag to use a custom file path. By default, it uses `/`.\r\n- The destination can be text, a file path, or a local address. Refer to [Tailscale Serve examples](https://tailscale.com/docs/reference/examples/serve) for more examples.\r\n\r\n#### [Layer 4 endpoints (transport layer)](https://tailscale.com/docs/features/tailscale-services\\#layer-4-endpoints-transport-layer)\r\n\r\nLayer 4 (transport) endpoints operate at the transport (TCP) layer of the [OSI model](https://tailscale.com/docs/concepts/tailscale-osi). They act as TCP forwarders that don't modify packet data, but might not preserve packet boundaries and metadata. These types of endpoints work well for standard TCP services like web servers and databases. They have less overhead than layer 7 endpoints because they don't parse application layer protocols.\r\n\r\nYou can create a layer 4 endpoint by setting the protocol value to `tcp` or `tls-terminated-tcp` when using `tailscale serve`.\r\n\r\n- The port number is the port to expose a TCP forwarder on. The TCP forwarder forwards raw TLS-terminated brackets.\r\n- You cannot use the `--set-path` flag to use a custom file path. It must be empty or unset.\r\n- The destination is the local address where the raw TCP packets will be forwarded to (for example, `tcp://localhost:5432`).\r\n\r\n#### [Layer 3 endpoints (network layer)](https://tailscale.com/docs/features/tailscale-services\\#layer-3-endpoints-network-layer)\r\n\r\nLayer 3 (network) endpoints are a special type of endpoint that operates at the IP packet level and forwards all traffic, unmodified, to the operating system networking stack.\r\n\r\nYou might consider using a layer 3 endpoint if the application or resource you're serving requires UDP support or you need to preserve exact packet boundaries and sizes. However, keep in mind that they have the following limitations:\r\n\r\n- Require additional operating system configuration to handle the unmodified packets.\r\n- Don't have any built-in application layer features like authentication headers.\r\n- Only work on Linux.\r\n\r\nYou can create a layer 3 endpoint on a Linux device by running the `tailscale serve` command (with the service information) with the `--tun` flag.\r\n\r\n```shell\r\ntailscale serve --service=svc: --tun\r\n```\r\n\r\nUsing the `--tun` flag creates a layer 3 protocol-agnostic endpoint, which offers more control over the way packets flow to the resource. This type of endpoint forwards all traffic heading to the Tailscale Service to your local device without modifying it. In this mode, you would likely be doing some of your own `iptables` configuration or something like that to take full control of the packet and make it go to your desired destination.\r\n\r\n### [Service states](https://tailscale.com/docs/features/tailscale-services\\#service-states)\r\n\r\nThis section covers the states of Services in the admin console. In the Services page of the admin console, a Service can be in the following states:\r\n\r\n- **Pending approval**: The Service has one or more hosts that have been advertised but are awaiting approval from an [Admin, Network admin, or Owner](https://tailscale.com/docs/reference/user-roles).\r\n- **Needs configuration**: The host has been defined but has an invalid or missing configuration.\r\n- **Connected**: At least one host is actively advertising the Service.\r\n- **Offline**: No hosts are currently advertising the Service.\r\n- **Pre-approved**: A device has been automatically approved based on an auto-approval policy but is not yet advertising the Service.\r\n- **Draining**: The host is in the process of draining, meaning it is no longer accepting new connections but is still handling existing ones.\r\n\r\n## [Limitations](https://tailscale.com/docs/features/tailscale-services\\#limitations)\r\n\r\nTailscale Services has the following limitations:\r\n\r\n- **TCP-only protocol support**: Services currently only support TCP transport protocol, with UDP unavailable except through layer 3 endpoints on Linux that require additional operating system (OS) level configuration.\r\n- **No outgoing connections**: Virtual IP addresses (TailVIPs) assigned to Services can only accept incoming connections, preventing any outgoing connections from being initiated.\r\n- **No hairpinning**: Service host devices cannot access the Services they host.\r\n- **Linux-only layer 3 endpoints**: Layer 3 endpoints that preserve packet boundaries only work on Linux and require additional tool configuration, such as `iptables`.\r\n- **Text and file endpoints**: The Service configuration file method does not support `text:` or `file:` destinations. These are only available when using the `tailscale serve` CLI command.\r\n- **Limitations with multiple network interfaces**: Service Hosts that have multiple network interfaces and define remote resource destinations might experience issues in specific circumstances. For example, a connection to a remote destination might fail if:\r\n - The Service Host (1) is a Linux device, (2) is running `tailscaled` without `SO_MARK`, (3) has multiple network interfaces, and (4) does not have the remote destination in its default route table. You can bypass this limitation by running `tailscaled` in [userspace-networking mode](https://tailscale.com/docs/reference/kernel-vs-userspace-routers#userspace-netstack-mode).\r\n - The Service Host (1) is a macOS device using the [Mac App Store or Standalone variant](https://tailscale.com/docs/concepts/macos-variants), (2) has multiple network interfaces, and (3) does not have the remote endpoint in its default route table. In this case, you can bypass the issue by running the [open source macOS variant](https://tailscale.com/docs/concepts/macos-variants#open-source-tailscaled-variant) (which uses `tailscaled` in userspace-networking mode by default).\r\n\r\n## [Additional information](https://tailscale.com/docs/features/tailscale-services\\#additional-information)\r\n\r\n- Use the [Services endpoint](https://tailscale.com/api#tag/services) in the [Tailscale API](https://tailscale.com/docs/reference/tailscale-api) to manage Services for your tailnet.\r\n - [List all services](https://tailscale.com/api#tag/services/get/tailnet/%7Btailnet%7D/services)\r\n - [Get a service](https://tailscale.com/api#tag/services/get/tailnet/%7Btailnet%7D/services/%7BserviceName%7D)\r\n - [Update a service](https://tailscale.com/api#tag/services/put/tailnet/%7Btailnet%7D/services/%7BserviceName%7D)\r\n - [Delete a service](https://tailscale.com/api#tag/services/delete/tailnet/%7Btailnet%7D/services/%7BserviceName%7D)\r\n - [List devices hosting a service](https://tailscale.com/api#tag/services/get/tailnet/%7Btailnet%7D/services/%7BserviceName%7D/devices)\r\n - [Get approval status of service on a device](https://tailscale.com/api#tag/services/get/tailnet/%7Btailnet%7D/services/%7BserviceName%7D/device/%7BdeviceId%7D/approved)\r\n - [Update approval status of service on a device](https://tailscale.com/api#tag/services/post/tailnet/%7Btailnet%7D/services/%7BserviceName%7D/device/%7BdeviceId%7D/approved)\r\n- For more information about using the [`tsnet`](https://tailscale.com/docs/features/tsnet) package and `Server.ListenService` with Go programs, refer to [`tsnet` server](https://tailscale.com/docs/reference/tsnet-server-api).\r\n- For a complete example that uses `Server.ListenService` and `ServiceModeHTTP` with Tailscale Services, refer to [`tsnet` and Tailscale Services](https://tailscale.com/docs/features/tsnet/how-to/register-service).\r\n\r\n![Project Logo](https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed)\r\n\r\nAsk AI\r\n\r\nreCAPTCHA\r\n\r\nRecaptcha requires verification.\r\n\r\nprotected by **reCAPTCHA**\r\n","html":"

Tailscale Services

\n

Last validated: Feb 2, 2026

\n

Services increase reliability, leverage Tailscale's access-controlled routing, and provide a centralized way to manage all internal resources available in your Tailscale network (known as a tailnet). You can focus on maintaining your applications while Tailscale handles the networking complexity.

\n

Tailscale Services let you publish internal resources (like databases or web servers) as named services in your tailnet.

\n

Instead of connecting to specific devices, users connect to Tailscale Services using stable MagicDNS names while Tailscale automatically routes traffic to available hosts across your infrastructure.

\n

This approach decouples your resources from the devices hosting them. For example, a database service remains accessible at the same address even when you migrate it to a different host, add redundant hosts for high availability, or route traffic across regions. You gain built-in traffic steering, granular access control, approval workflows, and the ability to configure different endpoint types for different layers of the networking stack.

\n

Use cases

\n

You can use Tailscale Services in a variety of scenarios to securely expose internal resources within your tailnet in a way that decouples them from the devices hosting them. For example:

\n
    \n
  • Developer workflows and internal tooling: Make any internal application or developer resource highly available, horizontally scalable, and secure without complex load balancer configurations.
    • \n
  • Database connectivity: Connect securely to database clusters (PostgreSQL, MySQL, RDS) with simplified connection scaling and identity-based access controls.
    • \n
  • Cluster meshes: Enable cross-cluster or hybrid-cloud connectivity between any compute resources like EC2 instances, Kubernetes services, or containers.
    • \n
  • Version-controlled applications: Generate stable hostnames for frequently updated, version-controlled, or ephemeral resources that persist across deployments.
    • \n
  • IoT integrations: Stream device logs and telemetry securely to SIEM or logging services without exposing IoT devices to the public internet.
    • \n
  • Internal APIs and webhooks: Expose internal APIs securely without public domains or complex mTLS configurations while maintaining granular access control.
    • \n
\n

Prerequisites

\n

To get started with Tailscale Services, you must have:

\n
    \n
  • An active tailnet.
    • \n
  • One or more devices running Tailscale v1.86.0 or later, or an unstable v1.87.x release.
    • \n
  • Owner, Admin, or Network admin account permissions.
    • \n
  • An internal resource running on a tailnet device that you want to expose as a Tailscale Service. The device hosting the resource must use a tag-based identity.
    • \n
\n

Get started

\n

To get started with Tailscale Services, you need to define a Service through the admin console, configure an endpoint on a tailnet device (the host), then advertise the endpoint.

\n

Step 1: Define a Tailscale Service

\n

You define a Tailscale Service using the admin console. Each Tailscale Service consists of a MagicDNS name, a TailVIP (Tailscale Virtual IP address), a resource definition, and one or more back-end hosts.

\n
    \n
  1. Open the Services page of the admin console.
    2. \n
  2. Select Advertise, and then select Define a Service.
    3. \n
  3. Within the Define a Service dialog, provide a name and description for your Service.
    4. \n
  4. Choose a port or set of endpoints your Service will advertise, including the tcp: transport protocol prefix (for example, tcp:443). Currently, TCP is the only supported transport protocol. Alternatively, enter do-not-validate to skip endpoint validation.
    5. \n
  5. (Optional) Provide the Service with an identity by adding one or more tags.
    6. \n
  6. Select Add service.
    7. \n
\n

You have now defined the Service interface. Next, you need to configure a tailnet device as a Service host.

\n

Step 2: Configure a Service host

\n

A Service host is a Tailscale device that runs the Tailscale client and advertises one or more endpoints for a specific Tailscale Service. The host handles incoming connections to the Service and routes them to the appropriate resource. Hosts can advertise both local and remote resources.

\n

Any device you want to use as a Service host must use a tag-based identity. You cannot use a device authenticated with a user account as a Service host.

\n

Make sure to start the resource on a tailnet device that you want to expose as a Tailscale Service. This resource can be a web server, database, or any other service that you want to make available through Tailscale.

\n

For example, you might start a basic web server using Node.js and the http-server package that listens on port 8080:

\n
# Install globally\r\nnpm install -g http-server\r\n\r\n# Then start a basic web server\r\nhttp-server -p 8080\n
\n

This example starts a basic web server that serves static files from the current directory on port 8080.

\n

After you have your resource running and listening for connections, you can configure it as a Service host.

\n

You can configure a Service host using either the tailscale serve CLI command or using a Service configuration file.

\n

Tailscale recommends using the CLI method because it automatically handles both configuration and advertisement, while the configuration file method gives you control over these as separate steps.

\n
    \n
  1. Run the tailscale serve command with the --service flag followed by the service name, the protocol, the port number, and the destination:
    2. \n
\n
tailscale serve --service=svc:web-server --https=443 127.0.0.1:8080\n
\n

The command returns output similar to the following:

\n
This machine is configured as a service host for `svc:web-server`, but approval from an admin is required. Once approved, it will be available in your Tailnet as:\r\n\r\nhttp://web-server.<tailnet-name>.ts.net:443/\r\n|-- proxy http://127.0.0.1:8080\n
\n

When you configure and advertise an endpoint using the tailscale serve CLI command, it automatically uses background mode (which you would normally need to use the --bg flag for when using the tailscale serve command).

\n

This command configures and automatically advertises an endpoint for the resource. When you use the tailscale serve command with the HTTPS protocol, Tailscale automatically provisions a TLS certificate for your unique tailnet DNS name.

\n
    \n
  1. Run the tailscale serve status command to verify your configuration:
    2. \n
\n
tailscale serve status --json\n
\n

To use regional routing's in-region load balancing with Tailscale Services, you will need to enable it on your tailnet.

\n

Step 3: Approve a Service host

\n

If your tailnet has auto-approval policies set up for the Service, the host is automatically approved. If not, an Admin, Network admin, or Owner must approve the host before it becomes active.

\n
    \n
  1. Open the Services page of the admin console.
    2. \n
  2. Select the name of the Service you created earlier.
    3. \n
  3. Locate the pending advertisements in the Service hosts section.
    4. \n
  4. Select Approve.
    5. \n
\n

After approval, the host becomes active and starts handling traffic for the Tailscale Service. Users in the tailnet can now connect to the Service using its MagicDNS name or IP addresses (provided they have the necessary access permissions).

\n

Step 4: Access Tailscale Services from other devices

\n

After you configure and approve a Tailscale Service, you need to ensure that other devices in your tailnet can discover and use the routes to the advertised resources.

\n

Tailscale clients version 1.94 and later no longer require enabling accept-routes to use Tailscale Services. This lets all clients leverage Tailscale Services by default while simultaneously not enabling accept-routes which can lead to route clashes.

\n

Linux devices running Tailscale version 1.93 or earlier don't discover new routes to Tailscale Services by default. You must explicitly enable accepting routes using the --accept-routes flag with the tailscale set command:

\n
sudo tailscale set --accept-routes\n
\n

Common scenarios

\n

This section covers common scenarios for managing Tailscale Service hosts, including draining a host, removing a host configuration, and updating a Service host configuration.

\n

Drain a host

\n

When you need to take a Service host offline, you should first drain the host. Draining a host stops it from accepting new incoming connections while letting existing connections to close gracefully.

\n

Use the tailscale serve drain command to stop the host from advertising itself for a service (svc:<service-name>):

\n
tailscale serve drain svc:<service-name>\n
\n

After you run the tailscale serve drain command, all associated endpoints on the host stop accepting new incoming connections. However, any ongoing connections remain alive until they close normally.

\n

After all connections close gracefully, you can safely remove all relevant endpoint configurations.

\n

Remove a host configuration

\n

Do not remove an endpoint configuration before draining it. Doing so abruptly ends all connections to the advertised resource.

\n

After draining the endpoint for a resource, you can remove its configuration using one of three ways: remove a specific endpoint (for a single protocol:port endpoint mapping), remove the entire host configuration, or reset the configuration file. The best method depends on how much of the configuration file you want to preserve.

\n

You can check your Service configuration file at any point using the tailscale serve status command.

\n
tailscale serve status -json\n
\n

Remove an endpoint

\n

If you configured multiple endpoints for a single resource using different port numbers or protocols, you can use the off argument to remove only a specific endpoint mapping. To remove a specific endpoint mapping for a resource for a specific port number, re-run the original tailscale serve command (that you used to configure the endpoint) with the off argument. You must run the command with the same values and flags as you did to set up the endpoint.

\n
tailscale serve --service:\"svc:<service-name>\" --https:<port> <additional-flags> off\n
\n

Adding the off argument at the end of the command you used to advertise the endpoint with the same flag removes the endpoint configured for a port. For example, have an endpoint for web-server on HTTPS port 443 and an endpoint for web-server on HTTP ports 80 and 3000 and you need to remove the endpoint for HTTPS port 443:

\n
    \n
  1. Run this command to disable its configuration for only HTTPS port 443:
    2. \n
\n
tailscale serve --service=\"svc:web-server\" --https=443 off\n
\n
    \n
  1. Then, re-advertise with only HTTP port 80:
    2. \n
\n
tailscale serve advertise svc:web-server\n
\n

Here's a more complete example of removing an endpoint:

\n
# Run tailscale up <...>\r\n# Set up a few L7 endpoints:\r\n\r\ntailscale serve --service=\"svc:web-server\" --https=443 8080\r\ntailscale serve --service=\"svc:web-server\" --https=443 --set-path /mt2 8081\r\ntailscale serve --service=\"svc:web-server\" --http=80 3000\r\n\r\n# When you want to modify config, drain it first.\r\n\r\ntailscale serve drain svc:web-server\r\n\r\n# Wait until all connections close.\r\n\r\n# To only remove the endpoint configuration for the /mt2 path on port 443:\r\n\r\ntailscale serve --service=\"svc:web-server\" --https=443 --set-path /mt2 off\r\n\r\n# Then, advertise it again and it will only create one endpoint on HTTPS port 443\r\n\r\ntailscale serve advertise svc:web-server\r\n\r\n# To remove the endpoint configuration for for HTTPS port 443:\r\n\r\ntailscale serve --service:\"svc:web-server\" --https=443 off\r\n# You will see a prompt asking you to confirm\r\n# After you confirm, it removes all configured endpoints on port 443 but preserves other port configured for the same service resource.\r\n# Advertise the service again without the removed HTTPS port:\r\n\r\ntailscale serve advertise svc:web-server\n
\n

Remove all endpoint mappings for a Service

\n

To remove the configuration for a specific Service (which can have one or more endpoints), use the tailscale serve clear command.

\n
tailscale serve clear svc:<service-name>\n
\n

This removes all endpoint configurations for the Service from service configuration file.

\n

Here's a more complete example of removing all endpoint configurations for a resource:

\n
# Run tailscale up <...>\r\n# Set up a few L7 endpoints:\r\n\r\ntailscale serve --service=\"svc:web-server\" --https=443 8080\r\ntailscale serve --service=\"svc:web-server\" --https=443 --set-path /mt2 8081\r\ntailscale serve --service=\"svc:web-server\" --http=80 3000\r\n\r\n# When you want to modify config, drain it first:\r\n\r\ntailscale serve drain svc:web-server\r\n\r\n# Wait until all connections close.\r\n\r\n# Remove the configuration for svc:web-server:\r\n\r\ntailscale serve clear svc:web-server\n
\n

Remove all Service configurations

\n

To reset the entire configuration file (removing all configured Service configurations), use the tailscale serve reset command.

\n
tailscale serve reset\n
\n

This removes all configured endpoints from the Services configuration file.

\n

Update a Service host configuration

\n

You can update or modify a host's Service configuration using the tailscale serve command or by editing the Service configuration file directly. You should drain the host before modification.

\n

To update an endpoint configuration for a given protocol, port, and path, run tailscale serve with the same flags. For example, to start an endpoint configured with HTTPS on port 443:

\n
    \n
  1. Run the following command to start an endpoint configured with HTTPS on port 443:
    2. \n
\n
tailscale serve --service=\"svc:web-server\" --https=443 https://localhost:443\n
\n
    \n
  1. Then, check the configuration with tailscale serve get-config --all:
    2. \n
\n
{\r\n     \"version\": \"0.0.1\",\r\n     \"services\": {\r\n       \"svc:web-server\": {\r\n         \"endpoints\": {\r\n           \"tcp:443\": \"https://localhost:443\"\r\n         }\r\n       }\r\n     }\r\n}\n
\n

To update the endpoint default path point to local port 8081:

\n
    \n
  1. Run the following command:
    2. \n
\n
tailscale serve --service=\"svc:web-server\" --https=443 https://localhost:8081\n
\n
    \n
  1. Then, check the configuration with tailscale serve get-config --all:
    2. \n
\n
{\r\n\"version\": \"0.0.1\",\r\n     \"services\": {\r\n       \"svc:web-server\": {\r\n         \"endpoints\": {\r\n           \"tcp:443\": \"https://localhost:8081\"\r\n         }\r\n       }\r\n     }\r\n}\n
\n

To run a different protocol on a port for a local resource, you need to remove the existing endpoint configuration on the port, then add the configuration again. For example, let's say you have an endpoint configured for my-web-app with HTTPS on port 443 pointed to a text example, but you need to update it to use HTTP instead of HTTPS:

\n
    \n
  1. Remove the endpoint configuration for port 443 by running the following command:
    2. \n
\n
tailscale serve --service=\"svc:my-web-app\" --https=443 off\n
\n
    \n
  1. Then, re-run the tailscale serve command to set up the endpoint with HTTP:
    2. \n
\n
tailscale serve --service=\"svc:my-web-app\" --http=443 http://localhost:8081\n
\n

The command returns output similar to the following:

\n
Available within your tailnet:\r\n\r\nhttp://web-server.king-grouse.ts.net:443/\r\n|-- text  \"example\"\n
\n

Configure a Service host using a configuration file

\n

To configure a Service host using the Service configuration syntax, you need to create a configuration file (such as serveconfig.json) that contains the configuration for the Service host. Note that when you use the configuration file method, you must configure each endpoint mapping, then advertise it as two separate steps.

\n
    \n
  1. Create a file named serveconfig.json that contains a tailscale serve configuration. This example configures an endpoint for a local web server exposed on port 443 over HTTPS:
    2. \n
\n
{\r\n\"version\": \"0.0.1\",\r\n     \"services\": {\r\n       \"svc:web-server\": {\r\n         \"endpoints\": {\r\n           \"tcp:443\": \"https://localhost:443\"\r\n         }\r\n       }\r\n     }\r\n}\n
\n
    \n
  1. Use the tailscale serve set-config command to apply the configuration file:
    2. \n
\n
tailscale serve set-config --all serveconfig.json\n
\n
    \n
  1. Run the tailscale serve status command to verify your configuration:
    2. \n
\n
tailscale serve get-config --all\n
\n
    \n
  1. Advertise the endpoint:
    2. \n
\n
tailscale serve advertise svc:<service-name>\n
\n

Your service host is now handling traffic for your Tailscale Service. You can validate this by running tailscale status --json | jq '.Self.CapMap.\"service-host\"' to check the service-host status.

\n

Set up automatic approval

\n

Tailscale clients can advertise new Service hosts, but administrators must approve or deny new advertisements (similar to subnet route approval). You can set auto-approval policies to enable certain clients, users, or tags to automatically advertise and approve new hosts for a specific Service or group of Services.

\n
    \n
  1. \n

    Go to the Access controls page of the admin console.

    \n
    2. \n
  2. \n

    Create an auto-approval policy to approve new hosts for an individual Tailscale Service or groups of Tailscale Services (defined by a tag). The following shows an example:

    \n
    3. \n
\n
\"autoApprovers\": {\r\n     \"services\": {\r\n       \"svc:<service-name>\": [\"tag:server\"],\r\n       \"tag:prod-service\": [\"tag:prod-infra\"]\r\n     },\r\n},\n
\n

You can use the visual policy editor to manage your tailnet policy file. Refer to the visual editor reference for guidance on using the visual editor.

\n

The example creates an auto-approval rule for Tailscale clients tagged with the tag:server to advertise new Service Proxies, for the Tailscale Service svc:<service-name>. Additionally, it specifies that Tailscale clients with the tag tag:prod-infra can advertise new Service Proxies, and automatically receive approval, for Tailscale Services with the tag tag:prod-service.

\n

Validate your Service

\n

You can validate that your Service successfully advertised locally, and that it passed validation. To do this, run the following tailscale status command and pass its output to the jq command-line JSON processor:

\n
tailscale status --json | jq '.Self.CapMap.\"service-host\"'\n
\n

The jq output should show the service-host status.

\n

Configure Service access

\n

You can use a Tailscale Service as a destination in grant access control policies.

\n
    \n
  1. Go to the Access controls page of the admin console.
    2. \n
  2. Create a grant rule that grants access to your Service. For example, this grant uses svc:web-server a destination, on port 443, with access granted to \"autogroup:member.
    3. \n
\n
{\r\n  \"src\":  [\"autogroup:member\"],\r\n  \"dst\":  [\"svc:web-server\"],\r\n  \"ip\": [\"443\"],\r\n},\n
\n

You can use the visual policy editor to manage your tailnet policy file. Refer to the visual editor reference for guidance on using the visual editor.

\n

You can also reference groups of Tailscale Services using a tag you've assigned to each Service. This example grants access to a group of production Services with access to the Service svc:database.

\n
{\r\n  \"src\":  [\"tag:prod-service\"],\r\n  \"dst\":  [\"svc:database\"],\r\n  \"ip\": [\"5432\"],\r\n},\n
\n

Use access control tests

\n

Tailscale Services are valid accept or deny destinations in access control tests.

\n

Check availability

\n

To check the availability of your Service, you can use the Services page of the admin console.

\n
    \n
  1. Open the Services page of the Tailscale admin console.
    2. \n
  2. Within the Advertised section, you should find your Tailscale Service listed with configured endpoints.
    3. \n
\n

Reference

\n

This section provides reference information about Tailscale Services, including endpoint types and service states.

\n

Endpoint types

\n

Tailscale supports three types of endpoints, each operating at different layers of the networking stack. While the OSI model isn't a perfect representation of modern networking, it provides a useful framework for understanding these distinctions. There are three different types of endpoints: layer 7 (application), layer 4 (transport), and layer 3 (network). This section explains each type, when to use them, and notes about their specific capabilities

\n

Layer 7 endpoints (application layer)

\n

Layer 7 (application) endpoints provide the most sophisticated forwarding mechanism by understanding and manipulating application layer protocols. It can inspect, modify, and route traffic based on application-specific content. These types of endpoints work well when you need Tailscale to inject authentication headers in the packets or path-based routing. For example, /api/* requests might go to one server while /static/* goes to another.

\n

You can create a layer 7 endpoint by setting the protocol value to http or https when using tailscale serve.

\n
    \n
  • The port number is the port to expose the endpoint on.
    • \n
  • You can use the optional --set-path flag to use a custom file path. By default, it uses /.
    • \n
  • The destination can be text, a file path, or a local address. Refer to Tailscale Serve examples for more examples.
    • \n
\n

Layer 4 endpoints (transport layer)

\n

Layer 4 (transport) endpoints operate at the transport (TCP) layer of the OSI model. They act as TCP forwarders that don't modify packet data, but might not preserve packet boundaries and metadata. These types of endpoints work well for standard TCP services like web servers and databases. They have less overhead than layer 7 endpoints because they don't parse application layer protocols.

\n

You can create a layer 4 endpoint by setting the protocol value to tcp or tls-terminated-tcp when using tailscale serve.

\n
    \n
  • The port number is the port to expose a TCP forwarder on. The TCP forwarder forwards raw TLS-terminated brackets.
    • \n
  • You cannot use the --set-path flag to use a custom file path. It must be empty or unset.
    • \n
  • The destination is the local address where the raw TCP packets will be forwarded to (for example, tcp://localhost:5432).
    • \n
\n

Layer 3 endpoints (network layer)

\n

Layer 3 (network) endpoints are a special type of endpoint that operates at the IP packet level and forwards all traffic, unmodified, to the operating system networking stack.

\n

You might consider using a layer 3 endpoint if the application or resource you're serving requires UDP support or you need to preserve exact packet boundaries and sizes. However, keep in mind that they have the following limitations:

\n
    \n
  • Require additional operating system configuration to handle the unmodified packets.
    • \n
  • Don't have any built-in application layer features like authentication headers.
    • \n
  • Only work on Linux.
    • \n
\n

You can create a layer 3 endpoint on a Linux device by running the tailscale serve command (with the service information) with the --tun flag.

\n
tailscale serve --service=svc:<service-name> --tun\n
\n

Using the --tun flag creates a layer 3 protocol-agnostic endpoint, which offers more control over the way packets flow to the resource. This type of endpoint forwards all traffic heading to the Tailscale Service to your local device without modifying it. In this mode, you would likely be doing some of your own iptables configuration or something like that to take full control of the packet and make it go to your desired destination.

\n

Service states

\n

This section covers the states of Services in the admin console. In the Services page of the admin console, a Service can be in the following states:

\n
    \n
  • Pending approval: The Service has one or more hosts that have been advertised but are awaiting approval from an Admin, Network admin, or Owner.
    • \n
  • Needs configuration: The host has been defined but has an invalid or missing configuration.
    • \n
  • Connected: At least one host is actively advertising the Service.
    • \n
  • Offline: No hosts are currently advertising the Service.
    • \n
  • Pre-approved: A device has been automatically approved based on an auto-approval policy but is not yet advertising the Service.
    • \n
  • Draining: The host is in the process of draining, meaning it is no longer accepting new connections but is still handling existing ones.
    • \n
\n

Limitations

\n

Tailscale Services has the following limitations:

\n
    \n
  • TCP-only protocol support: Services currently only support TCP transport protocol, with UDP unavailable except through layer 3 endpoints on Linux that require additional operating system (OS) level configuration.
    • \n
  • No outgoing connections: Virtual IP addresses (TailVIPs) assigned to Services can only accept incoming connections, preventing any outgoing connections from being initiated.
    • \n
  • No hairpinning: Service host devices cannot access the Services they host.
    • \n
  • Linux-only layer 3 endpoints: Layer 3 endpoints that preserve packet boundaries only work on Linux and require additional tool configuration, such as iptables.
    • \n
  • Text and file endpoints: The Service configuration file method does not support text: or file: destinations. These are only available when using the tailscale serve CLI command.
    • \n
  • Limitations with multiple network interfaces: Service Hosts that have multiple network interfaces and define remote resource destinations might experience issues in specific circumstances. For example, a connection to a remote destination might fail if:\n
      \n
    • The Service Host (1) is a Linux device, (2) is running tailscaled without SO_MARK, (3) has multiple network interfaces, and (4) does not have the remote destination in its default route table. You can bypass this limitation by running tailscaled in userspace-networking mode.
      • \n
    • The Service Host (1) is a macOS device using the Mac App Store or Standalone variant, (2) has multiple network interfaces, and (3) does not have the remote endpoint in its default route table. In this case, you can bypass the issue by running the open source macOS variant (which uses tailscaled in userspace-networking mode by default).
      • \n
    \n
    • \n
\n

Additional information

\n\n

\"Project

\n

Ask AI

\n

reCAPTCHA

\n

Recaptcha requires verification.

\n

protected by reCAPTCHA

\n"}