Separate internal service networking from deliberate external exposure
Sidecarless service meshes and outbound tunnels can both influence how traffic reaches an application, but they solve different architectural problems. A mesh primarily governs communication among workloads inside a cluster or private environment. An outbound tunnel publishes a selected service through a connection initiated from the private side. This guide maps east-west traffic, public ingress, NAT traversal, Kubernetes exposure, developer access, and workload policy to the right connectivity layer, then explains how the two approaches can coexist.
📋 What's in this guide
Sidecarless service mesh vs outbound tunnel: the quick answer
A sidecarless service mesh is an internal application-networking layer. It moves some or all mesh data-plane functions out of individual application pods while retaining centralized control over workload communication. Depending on the mesh and its configuration, those functions can include workload identity, transport security, authorization, traffic policy, and telemetry. The important architectural point is not where every proxy process runs. It is that the mesh governs communication between participating workloads.
An outbound tunnel addresses a different requirement. A client inside a private network initiates an outbound connection to a relay, and the relay provides a public URL or a public host and port for a deliberately selected local service. With Localtonet, this makes it possible to expose a service, device, or agent without configuring inbound router port forwarding, changing an inbound firewall, setting up a VPN, or requiring a public IP address.
Moving from per-pod sidecars to an ambient or sidecarless data plane does not automatically make an application publicly reachable. It also does not remove the need to choose an ingress method, authenticate external users, limit the exposed surface, or account for NAT and firewall boundaries. Likewise, adding an outbound tunnel does not provide service-mesh functions to all workloads in a cluster. It does not become a substitute for internal workload identity, east-west authorization, service discovery, or mesh-wide traffic policy.
Use a service mesh to control how participating services communicate with one another. Use an outbound tunnel when a specific private endpoint must be reachable from outside its current network boundary. Use both when the externally exposed endpoint also participates in an internally governed service architecture.
This distinction prevents a common design error: comparing the two technologies as if they were interchangeable ingress products. A change in the mesh data plane can reduce application-pod coupling or alter how internal traffic is intercepted, but it does not answer who should be allowed to call a public endpoint, which endpoint should be published, or how an external connection reaches a cluster that has no usable inbound path.
Start with the traffic direction and trust boundary
Before choosing a networking component, describe the traffic flow in plain terms. Identify the source, destination, protocol, trust boundary, and expected lifetime. This exercise usually reveals whether the problem belongs to a service mesh, an ingress layer, an outbound tunnel, a private network, or more than one of them.
East-west traffic
East-west traffic normally refers to communication among application components rather than traffic entering from a public user-facing edge. In Kubernetes, examples include an API calling an internal account service, a worker connecting to a queue, or one namespace reaching a service in another namespace. A service mesh is relevant when the platform team needs consistent policy or observability across those connections.
A sidecarless architecture changes how mesh capabilities are delivered. Instead of placing a general-purpose proxy beside every application container, a mesh may use node-level transport components and selectively deployed higher-level proxies. The exact implementation varies, so teams should verify the behavior and guarantees of their chosen mesh rather than assuming that every “ambient” implementation provides the same policy model.
The absence of per-pod sidecars does not mean the absence of a data plane. Traffic still has to be captured, identified, secured, routed, or observed somewhere. Platform teams should therefore evaluate failure domains, resource allocation, upgrade procedures, policy semantics, and compatibility with the cluster network. Sidecarless describes deployment architecture, not an automatic solution to every connectivity requirement.
North-south traffic
North-south traffic crosses an application boundary. It can arrive through a load balancer, ingress controller, gateway, reverse proxy, outbound tunnel relay, or another explicitly designed edge. This path must answer questions that an internal mesh alone cannot settle: Is the destination intended to be public? Which public address should clients use? Where is external authentication enforced? Is the endpoint permanent or temporary? What happens when the private environment cannot accept an inbound connection?
An outbound tunnel is useful when the destination is behind carrier-grade NAT, a home router, a restrictive network, or another boundary where direct inbound routing is unavailable or undesirable. Because the tunnel connection originates from the client side, the network does not need an inbound port-forwarding rule for the selected service. That solves reachability, but the application owner must still decide whether the service is safe to expose.
Control-plane direction is not application-traffic direction
The phrase “outbound tunnel” describes how the tunnel is established, not necessarily the direction of every application request. The Localtonet client establishes an outbound connection to our relay. A remote user can then send application traffic through the assigned public endpoint toward the configured local target. This distinction matters when reviewing network diagrams and firewall policy.
The local target can be a service on the same machine as the Localtonet client or another service reachable from that device. In a Kubernetes design, that means the client must have a valid network path to the chosen service endpoint. The exact placement depends on cluster policy and topology. It might run in an environment that can reach a cluster service, but this article does not prescribe a Kubernetes manifest, container image, namespace, or service-account configuration because those deployment details must be validated against the current client distribution and the cluster's security requirements.
What each connectivity layer should own
Architecture becomes easier to reason about when each component has a narrow responsibility. The mesh should not be expected to solve public DNS and NAT traversal merely because it processes service traffic. The tunnel should not be expected to provide mesh-wide identity and policy merely because it carries traffic to one service.
| Requirement | Sidecarless service mesh | Outbound tunnel | Design guidance |
|---|---|---|---|
| Internal service-to-service communication | Primary concern | Not a mesh replacement | Use the mesh for participating workload communication and policy. |
| Workload identity and east-west authorization | Common mesh responsibility, subject to the chosen implementation | Does not establish a cluster-wide workload identity model | Keep internal identity and authorization in the application or mesh layer. |
| Public URL for a private HTTP service | Not automatically provided by becoming sidecarless | HTTP tunnels provide a public HTTPS address | Publish only the intended local target and apply suitable access controls. |
| Public host and port for a raw service | Outside the basic east-west mesh purpose | Supported through an appropriate TCP, UDP, combined UDP/TCP, or TLS tunnel | Match the tunnel family to the actual application protocol. |
| NAT traversal without inbound port forwarding | Not inherently solved by an internal mesh | Core outbound-tunnel use case | Run the tunnel client where it can reach the service and establish the outbound connection. |
| Permanent production ingress | May integrate with gateways, depending on the mesh | Can publish a selected endpoint, but architecture and plan requirements must be reviewed | Evaluate lifecycle, capacity, access policy, operational ownership, and dependency requirements. |
| Temporary developer preview | Usually more machinery than the exposure itself requires | Well aligned with narrowly scoped, reversible access | Start the tunnel for the required period, verify the target, then stop or delete it. |
| Broad private connectivity among networks | May govern workloads but is not automatically a general remote-access network | A standard HTTP, TCP, or UDP tunnel exposes selected services rather than creating a VPN | Use a purpose-built private networking design. Localtonet VPN Manager is the actual mesh VPN feature. |
| Application authentication | May enforce workload-level policy internally | Does not remove the target application's authentication responsibility | Require appropriate application or edge authentication for exposed services. |
What a sidecarless mesh changes
The main change is the location and granularity of mesh processing. Removing per-pod sidecars can decouple some network-component lifecycles from application-pod lifecycles. It can also let an implementation separate basic transport processing from optional application-aware processing. Those are valuable internal platform concerns, but they do not redefine a private service as public.
Teams should also avoid assuming that “sidecarless” means “proxyless” or “policy-free.” A mesh still needs components that participate in traffic handling and control. Application-aware routing may still require an additional proxy tier. Enrollment boundaries, unsupported protocols, traffic capture, identity issuance, and policy evaluation remain implementation-specific topics that require testing.
What an outbound tunnel changes
An outbound tunnel changes the reachability path for one or more deliberately configured endpoints. With Localtonet, the client authenticates as a device, connects to a selected relay server, and runs the chosen tunnel. A Localtonet HTTP, raw port, or TLS tunnel points to a local IP address and port on or reachable from the client device. The public endpoint remains available only while the selected client is connected and the tunnel is running.
This model is useful when inbound network configuration is impossible, slow, risky, or disproportionate to the task. It is also reversible. Stopping the tunnel removes that tunnel's active public path. Deleting it removes the saved tunnel configuration. Neither action changes the internal service-mesh architecture.
Publishing a service creates a path to it. It does not automatically make an unauthenticated application safe. Before starting a tunnel, verify the target, remove unnecessary administrative routes, require suitable authentication, apply least privilege, and use application-level authorization or other available access restrictions. Never expose a cluster control plane, datastore, management console, or debug endpoint merely because it is technically reachable.
Choose the right layer for the actual requirement
A useful decision process begins with the narrowest statement of need. “We need connectivity” is too broad. “A payment provider must deliver HTTPS callbacks to one application route for two days of integration testing” is specific enough to evaluate.
Choose a sidecarless service mesh when the requirement is internal policy
A service mesh is the more appropriate layer when the primary objective is to manage communication among workloads. Examples include enforcing which internal service identities may connect, applying consistent service-to-service transport policy, collecting mesh-level telemetry, or introducing controlled application routing among participating services.
The decision to use a sidecarless design should be based on the mesh's operational model, supported features, upgrade process, data-plane behavior, and compatibility with existing Kubernetes networking. It should not be justified solely as a way to expose an internal application to public users. Public ingress remains a separate design decision.
Choose an outbound tunnel when the requirement is selected external reachability
An outbound tunnel is appropriate when a known endpoint inside a private environment needs a public access path and conventional inbound networking is unavailable or unnecessary. Typical examples include receiving third-party webhooks during development, sharing an internal preview with an authorized reviewer, remotely reaching a selected TCP service, or testing an integration from a network outside the cluster.
The tunnel should be scoped to the actual protocol and destination. For a web application, that normally means an HTTP tunnel to the application's reachable IP address and port. For a raw TCP or UDP application, use the matching tunnel family instead of trying to treat all traffic as HTTP. Protocol selection matters because application clients expect different connection behavior.
Choose conventional ingress when the endpoint is a stable application edge
A load balancer, ingress controller, or gateway may be the natural choice for a long-lived production application that already runs in a cluster with managed public networking. Such an ingress can align with cluster-native service discovery, infrastructure-as-code workflows, certificate management, policy enforcement, and established production operations.
Outbound tunnels can still be relevant in production, especially where inbound network paths are unavailable, but the decision should be deliberate. Teams should assess dependency ownership, availability requirements, expected protocols, client lifecycle, relay selection, observability, capacity, incident procedures, and subscription-specific capabilities. We do not claim that every protocol, option, region, or capability is included in every Localtonet plan, so current dashboard and plan details should be verified during design.
Choose private networking when users need broad network membership
If a remote user needs access to many private addresses and services as though connected to a private network, repeatedly creating public tunnels may be the wrong abstraction. Standard Localtonet HTTP, TCP, UDP, TLS, combined UDP/TCP, and File Server tunnels expose selected targets. They should not be described as VPN connections.
Localtonet VPN Manager is our actual VPN capability. It provides a private mesh VPN with granular firewall rules and can bridge local LANs. That is distinct from using an outbound tunnel to publish one application endpoint. Keeping these models separate helps prevent accidental overexposure.
Use more than one layer when responsibilities overlap
A Kubernetes service can participate in a service mesh and still need an external entry path. In that design, the tunnel handles reachability from the public endpoint to a selected local target, while the mesh continues to govern applicable communication inside its boundary. The application still owns its business-level authentication and authorization.
This layered arrangement is not redundant. Each layer answers a different question:
- Can the external client reach a public endpoint?
- Which private service receives traffic from that endpoint?
- How is traffic handled after it enters the internal service environment?
- Which workload identities may communicate internally?
- Which end users or systems are authorized to invoke the application?
- How is the public path disabled when it is no longer required?
How a sidecarless mesh and Localtonet can coexist
The safest integration pattern is to treat the tunnel endpoint as an explicit edge adapter, not as an invisible shortcut around cluster policy. The Localtonet client must run on a device that can reach the chosen local target. That target should be an intentionally exposed service interface rather than an arbitrary pod address or internal administrative port.
Pattern 1: expose a dedicated application gateway
A dedicated application gateway or narrowly scoped service can be the local target. The gateway receives traffic from the tunnel and forwards allowed requests through the normal application path. This approach creates a clear boundary where authentication, route restrictions, request validation, and application logging can be applied.
The internal mesh can continue to govern calls from that gateway to downstream workloads. The tunnel does not need to understand internal service identities or routing rules. Its job is to connect the public endpoint to the selected reachable target.
Pattern 2: expose a development service without changing permanent ingress
During development, a team may need an external callback or preview URL before the permanent ingress configuration exists. A Localtonet HTTP tunnel can publish the selected web endpoint without requiring inbound router configuration or a public IP. This is particularly useful for short-lived testing because the tunnel can be stopped after the session.
Temporary does not mean unprotected. Development environments often contain verbose error messages, test credentials, mock administration routes, or data that should not be public. Apply the same authentication and route minimization principles that would be used for a permanent edge.
Pattern 3: expose a non-HTTP integration endpoint
Some systems communicate over raw TCP or UDP rather than HTTP. Localtonet supports TCP, UDP, combined UDP/TCP, and TLS tunnel families in addition to HTTP/s. The correct choice depends on what the application actually listens for and what the remote client expects.
A service mesh may still govern internal connections before or after that exposed component, but it does not change the remote client's protocol. Do not wrap an arbitrary protocol in an HTTP tunnel merely to obtain a URL. Select the matching tunnel type and preserve the application's own authentication and protocol safeguards.
Pattern 4: place the client outside the cluster but within reach
The client does not have to be described as a mesh workload merely to reach a service. It may run on a device or host that has a permitted route to the target. This can reduce coupling between the tunnel lifecycle and application pods, but it requires careful network policy. Permit only the destination and port the client needs, and avoid broad access to cluster networks.
Pattern 5: run near the workload with tightly scoped permissions
Some teams may prefer to place a connectivity component close to the workload. If the current Localtonet client packaging and the organization's Kubernetes standards support that deployment, the design should still use a dedicated identity, minimal runtime permissions, restricted egress, and a narrowly reachable target.
This guide intentionally does not invent a Localtonet Kubernetes manifest, container image name, command-line flag, secret key, namespace, health probe, or service-account requirement. Those values are not established by the supplied product context. Use the current Localtonet client distribution and dashboard instructions, then review the resulting deployment against your cluster's admission, secret-management, and network-policy standards.
Publish a selected service with Localtonet
The following workflow preserves the documented Localtonet lifecycle at a platform level. It applies when a reachable HTTP, TCP, UDP, combined UDP/TCP, or TLS service has already been identified. Before beginning, record the target IP address, target port, application protocol, intended audience, authentication method, and planned exposure duration.
Do not place a real device token in a manifest, article, ticket, chat message, or source repository. A token identifies the client device and must be treated as a secret. Available relay server codes or regions should be obtained from the current Localtonet product or dashboard rather than copied from an old example.
Install and run the Localtonet client
Install the current Localtonet client on the device that can reach the selected service. Confirm that this device has a valid network path to the application's IP address and port before adding public exposure. The client establishes the outbound connection, so it must remain running for the tunnel to stay available.
Authenticate or select the device
Authenticate the client with its device-specific token, or select the already registered device in the Localtonet workflow. Keep the token private. Do not reuse an undocumented value or guess a token, because it identifies the device responsible for running the tunnel.
Select an available relay server or region
Choose from the relay server or region values currently available in the dashboard. Availability can vary, so this article does not hardcode a server code. Make the selection according to the options shown for the account and current configuration.
Create the appropriate tunnel configuration
Choose the tunnel family that matches the service protocol, then configure the local IP address and port on or reachable from the client device. Use HTTP for a web endpoint and the appropriate raw-port or TLS option for services that require it. Creating the configuration does not start the tunnel.
Start the tunnel and test the assigned endpoint
Press Start, then use the assigned public URL or public host and port. Verify the intended route from a network outside the private environment. Confirm both successful authorized access and expected rejection of unauthorized or out-of-scope requests.
Stop or delete the tunnel when it is no longer needed
Stop the tunnel to remove its active public path while retaining the configuration for later use. Delete it when the configuration itself is no longer required. Remember that the public endpoint is available only while the selected device is connected and the tunnel is running.
Verify the local target before testing publicly
A tunnel cannot repair an unreachable or misconfigured local service. From the Localtonet client device, verify that the target address resolves or routes correctly, that the service listens on the expected port, and that local or cluster policy permits the connection. For HTTP, test the precise route and expected host behavior. For TCP or UDP, use a protocol-aware client rather than relying only on whether a port appears open.
Verify the public path from outside
Test from a separate network when possible. A successful test should prove more than basic connectivity. Confirm that the correct application answers, authentication is required where intended, sensitive routes are unavailable, and the application records enough information for operational review. If a third-party webhook system is the consumer, send a representative signed or authenticated request rather than only opening the URL in a browser.
Understand the tunnel lifecycle
A saved tunnel is not necessarily active. It has to be started, and the selected client device must remain connected. This state model is useful for temporary access because exposure can be intentionally removed without changing the application deployment. It also means production monitoring should distinguish among application health, client connectivity, and tunnel status.
Localtonet provides platform-wide Token/Tunnel webhooks for status changes in a selected Token Group. These webhooks can report when a token or tunnel becomes Connected or Disconnected. They send a JSON body containing an identifier, action date, type, and status. This platform status system is separate from File Server file-event webhooks and should not be confused with application request logging or application-level health checks.
Security design for a layered deployment
The safest design treats every crossing between layers as an explicit trust-boundary transition. The public endpoint, tunnel client, target service, mesh edge, downstream workload, and end user can each have a different identity and threat model. Do not assume that security at one layer automatically covers all others.
Expose a purpose-built target
Prefer a dedicated application endpoint with a narrow route set over a broad administrative interface. If an integration needs one webhook route, avoid publishing the entire internal management application. If a developer needs a preview, avoid exposing diagnostic endpoints, metrics, dashboards, or framework consoles through the same listener.
Preserve application authentication
The tunnel provides reachability to the configured target. The target should still authenticate users or calling systems as appropriate. For machine-to-machine callbacks, use the integration's documented signing or credential model. For human users, use an established application authentication flow. Avoid relying on a hard-to-guess public address as the only protection.
Apply least privilege around the client
The machine running the Localtonet client should have only the network reachability and operating permissions it needs. In a Kubernetes-adjacent deployment, restrict the client's path to the target service and port rather than granting broad access to pod or node networks. Protect the device token through the organization's secret-management process, and do not embed it in public configuration.
Keep internal mesh policy intact
If traffic enters through a gateway that participates in the mesh, downstream calls should continue through the intended mesh-controlled path. Do not create an alternate route to workloads solely to avoid authorization policy. The tunnel should provide an edge path, not a mechanism for bypassing network controls.
Separate transport reachability from user authorization
A connection can successfully traverse a tunnel and still be unauthorized at the application. That is a correct outcome when the caller lacks permission. Monitoring should distinguish network failures, tunnel lifecycle failures, application authentication failures, policy denials, and application errors rather than grouping all failures under “the tunnel is down.”
Plan revocation before exposure
Decide who can stop the tunnel, who can delete it, how device access is revoked, and what happens when the client host is lost or decommissioned. Temporary exposure should have a clear owner and end time. For ongoing exposure, include tunnel state and client state in operational reviews.
Kubernetes APIs, node administration interfaces, database administration ports, container runtimes, dashboards, and debug consoles require specialized protection. A public path should not be created merely for convenience. Use a narrowly designed application interface, enforce authentication, and follow the organization's access-control and network-security policies.
Operations, verification, and troubleshooting
A layered architecture is easier to operate when tests proceed from the innermost dependency to the outermost endpoint. Starting with the public URL can hide the difference between an application fault, an internal policy denial, a target-address error, a disconnected client, and a stopped tunnel.
1. Confirm that the application is healthy
Verify the service at its normal local or cluster access point. Check that it listens on the intended protocol and port and returns the expected application response. If the service is unhealthy locally, fix that issue before investigating the tunnel.
2. Confirm reachability from the client device
Test the exact target from the environment where the Localtonet client runs. A service may be healthy from inside its own pod but unreachable from another node, namespace, host, or private network. Review routing, service selectors, endpoint availability, network policy, and host firewall rules according to the deployment architecture.
3. Confirm mesh enrollment and policy behavior
If the target or gateway participates in a sidecarless mesh, determine whether traffic from the client enters through an enrolled and authorized path. A denial can be an expected policy outcome rather than a tunnel failure. Review the mesh's own telemetry and policy status using the tools documented for that implementation.
4. Confirm the selected Localtonet device is connected
The tunnel depends on the selected client device. If the device is offline, stopped, unauthenticated, or unable to reach the relay, the public endpoint cannot forward traffic to the target. Confirm device state before changing application or mesh configuration.
5. Confirm that the tunnel is started
Creating a tunnel does not start it. Check its lifecycle state and start it if appropriate. If it repeatedly disconnects, investigate the client host's outbound connectivity, lifecycle, power state, process supervision, and applicable local network policy.
6. Confirm protocol and target settings
An HTTP client cannot validate an arbitrary UDP service, and a raw TCP tunnel should not be expected to provide web-specific behavior. Confirm that the tunnel family matches the application protocol and that the configured local IP address and port identify the intended service from the client's perspective.
7. Test the public endpoint externally
Use a representative remote client from outside the private network. For web traffic, test the required route, method, headers, authentication, and payload. For raw protocols, use the real application client or a protocol-aware diagnostic tool. Record whether failure occurs before connection, during protocol negotiation, during authentication, or inside application processing.
8. Review lifecycle dependencies
If access disappears after a pod rollout or node replacement, determine whether the Localtonet client was coupled to an ephemeral environment or whether its route to the target changed. A sidecarless mesh may reduce one form of pod-level coupling, but it does not automatically preserve an independently deployed tunnel client or an obsolete target address.
| Symptom | Likely layer | What to check |
|---|---|---|
| The application fails locally | Application or workload | Process health, listener, dependency health, configuration, and local logs |
| The app works locally but not from the tunnel client | Routing, service discovery, firewall, or cluster policy | Target address, target port, service endpoints, network policy, and client-to-target route |
| The client reaches the target but the public endpoint is unavailable | Localtonet client or tunnel lifecycle | Selected device connectivity, authentication state, relay reachability, and whether the tunnel was started |
| A connection succeeds but the application returns a denial | Application or mesh authorization | User credentials, machine identity, route permission, workload policy, and expected audience |
| HTTP works on one route but not another | Application routing or gateway policy | Path, method, host handling, authentication rules, and gateway route configuration |
| Access stops after a restart or rollout | Lifecycle or target stability | Client process state, device connectivity, tunnel state, service address, and deployment placement |
| A raw-protocol client cannot negotiate | Protocol mismatch or application listener | Tunnel family, TCP versus UDP behavior, TLS expectations, and target port |
Operational ownership
Assign ownership across layers before an incident. The platform team may own mesh enrollment and internal policy, the network or infrastructure team may own the tunnel client environment, and the application team may own authentication and route behavior. A single runbook should show how these responsibilities connect without assuming that one team's dashboard explains every failure.
Monitoring boundaries
At minimum, distinguish application health, client device connectivity, tunnel status, target reachability, and end-to-end request success. Platform-wide Localtonet Token/Tunnel webhooks can help with Connected and Disconnected state changes, but they are not a replacement for application monitoring. Similarly, a healthy application process does not prove that the external path is available.
Frequently asked questions
Does a sidecarless service mesh replace an ingress controller?
No. A sidecarless mesh changes how internal mesh functions are delivered, but it does not automatically create a public endpoint or define external access policy. A cluster may still use an ingress controller, gateway, load balancer, outbound tunnel, or another explicit edge, depending on its requirements.
Is a Localtonet HTTP or TCP tunnel a service mesh?
No. A Localtonet tunnel publishes a selected local service through a public URL or public host and port. It does not provide a cluster-wide workload identity, east-west policy, or service-to-service routing model. It can coexist with a service mesh by forwarding external traffic to an intentionally selected edge service.
Is a standard Localtonet tunnel a VPN?
No. HTTP, TCP, UDP, combined UDP/TCP, TLS, and File Server tunnels expose selected services or folders. They should not be described as VPN connections. Localtonet VPN Manager is our private mesh VPN feature and includes granular firewall rules for private networking use cases.
Can an outbound tunnel work through NAT without port forwarding?
Yes. The Localtonet client establishes an outbound connection to our relay, so the selected service can be exposed without configuring inbound router port forwarding, requiring a public IP address, or setting up a VPN. The local network must still permit the client's outbound connection, and the client must be able to reach the target service.
Where should the Localtonet client run for a Kubernetes service?
It must run on a device that can reach the selected service's IP address and port. The best placement depends on the cluster topology, security policy, client distribution, and lifecycle requirements. This guide does not prescribe an unverified Kubernetes manifest or container configuration. Whichever placement is chosen, protect the device token and grant only the network and runtime permissions required.
Does creating a Localtonet tunnel make it active immediately?
No. Creating the tunnel saves its configuration. It must also be started, and the selected client device must remain connected. The tunnel can later be stopped or deleted when access is no longer required.
Which Localtonet tunnel type should be used for Kubernetes service exposure?
Match the tunnel to the application's actual protocol. Use an HTTP tunnel for a web service and the appropriate TCP, UDP, combined UDP/TCP, or TLS tunnel for a compatible raw service. Do not select a protocol based only on convenience. Confirm what the application listens for and what the remote client expects.
Can Localtonet bypass service-mesh authorization or cluster policy?
It should not be designed or described that way. The client needs a permitted route to the selected target, and the application and mesh should continue to enforce their intended controls. Use the tunnel as a deliberate external access path, not as a method for avoiding authorization, firewall policy, or organizational security requirements.
Expose the endpoint you intend, not the whole network
With Localtonet, you can create an outbound tunnel for a selected HTTP, TCP, UDP, combined UDP/TCP, or TLS service while keeping your internal service-mesh responsibilities separate. Start with a narrowly scoped target, verify authentication and local reachability, then stop the tunnel when external access is no longer needed.
Get Started Free →
