Publish the avatar interface, not the private GPU stack
A self-hosted AI avatar service often combines a browser interface, media-upload API, job queue, model runtime, GPU worker, temporary storage, and result-delivery path. Exposing that entire stack directly creates unnecessary risk. In this guide, we show how to place a narrowly scoped local gateway in front of the application and expose only that gateway with a Localtonet HTTP tunnel, without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. We also cover uploads, asynchronous jobs, progress reporting, previews, downloads, security controls, operations, troubleshooting, and protocol planning for real-time avatar workloads.
📋 What's in this guide
Design a safe public architecture for an AI avatar service
The safest exposure boundary is usually not the avatar model process itself. It is a small web application or API gateway that accepts a limited set of requests, validates them, submits work to private components, and returns controlled responses. The GPU worker, queue, model server, database, object store, and administrative tools should remain inaccessible from the public tunnel unless there is a specific and reviewed reason to publish them.
This separation matters because media-generation stacks often grow organically. A development deployment might include a web interface that calls a model server directly, a queue dashboard with no authentication, a temporary-output directory served by a basic development server, and an unrestricted API that accepts local file paths. That can work on a trusted workstation, but it is not an appropriate public boundary.
A better design treats the public avatar application as an orchestrator. The browser or API client communicates with one local HTTP gateway. That gateway performs authentication and authorization, checks uploaded media, creates jobs, exposes narrowly scoped status endpoints, and authorizes result downloads. Internal calls from the gateway to the model runtime remain on the machine or private LAN.
With Localtonet, an HTTP tunnel points to a local IP address and port reachable from the device running our client. The tunnel does not need to know how the private inference stack is assembled. It only needs a reachable HTTP target. This makes the local gateway the natural boundary between public traffic and private GPU infrastructure.
Publishing an HTTP endpoint makes that endpoint reachable through its assigned public address. The avatar application must still enforce authentication, authorization, request validation, safe file handling, and resource limits. Do not rely on an obscure URL as the only access control.
Map avatar generation to a web-friendly workflow
AI avatar systems differ in their models and rendering methods, but many remote-facing workflows share the same application pattern. A user uploads one or more inputs, creates a generation job, monitors progress, previews intermediate or final media, and downloads the result. Modeling these actions explicitly produces a safer and more reliable interface than holding one HTTP request open for an entire GPU render.
1. Upload source media
An upload might contain a portrait, source video, audio track, script, reference image, motion signal, or configuration document. The gateway should accept only the input types the selected workflow actually requires. It should reject oversized or malformed requests before they consume significant disk, memory, decoder, or GPU resources.
Store each accepted upload under a server-generated identifier. Do not use an untrusted filename as a storage path, and do not allow a client to choose an arbitrary local destination. Preserve an original filename only as non-authoritative metadata if the interface needs to display it.
2. Create an asynchronous generation job
Avatar rendering can be expensive and unpredictable. Duration depends on input length, output dimensions, frame rate, model state, available GPU memory, queue depth, and the implementation itself. A robust API therefore creates a job and returns an opaque job identifier instead of keeping the upload request open until rendering finishes.
The job record should belong to the authenticated user or access scope that created it. The gateway can then place a trusted internal message on a queue for the private worker. Public clients should not be able to insert unrestricted worker commands, filesystem paths, model paths, shell arguments, or callback destinations.
3. Report state and progress
A simple status endpoint can return states such as queued, running, completed, failed, cancelled, or expired. Exact state names are an application design decision, but they should be documented and stable. If numeric progress is available, make clear whether it represents frames processed, pipeline stages, estimated completion, or another measurement.
Polling is usually the simplest remote-access design because it uses ordinary HTTP requests and recovers naturally from a temporary disconnection. Server-sent events or WebSocket-based updates may provide a more immediate interface, but compatibility must be tested against the exact application behavior and current tunnel configuration. Do not assume that a browser interface is using ordinary short-lived HTTP merely because it loads over HTTP.
4. Serve previews safely
A preview endpoint should return only media associated with a job the requester is allowed to view. Avoid exposing a temporary-output directory through directory listing. If previews are regenerated or replaced, use identifiers that cannot be converted into arbitrary filesystem paths.
Decide whether previews may be cached. Avatar images and videos can contain biometric, personal, confidential, or licensed material. Application responses should use cache behavior appropriate to the sensitivity of the content and the intended clients.
5. Authorize result downloads
Completion should not turn an internal output folder into a public file share. Deliver the result through an authenticated route, a short-lived application-generated download mechanism, or another controlled storage workflow. A valid job identifier alone should not automatically prove that a requester may download its output.
6. Expire and delete artifacts
Uploads, extracted frames, audio intermediates, checkpoints, previews, final videos, logs, and failed-job remnants can consume storage rapidly. Define retention independently for each category. Cleanup should cover successful, failed, cancelled, abandoned, and partially uploaded jobs.
| Public operation | Recommended application behavior | Keep private |
|---|---|---|
| Media upload | Authenticate, limit size, validate type, generate a storage name, and return an opaque media identifier | Host paths, raw temporary directories, and decoder controls |
| Create job | Validate parameters, enforce quotas, create an owned job record, and enqueue trusted work | Worker command line, model filesystem paths, and unrestricted pipeline graphs |
| Read progress | Return a limited status document for a job the requester owns or may access | Queue administration, worker diagnostics, and other users' jobs |
| View preview | Authorize the request and stream only the expected preview asset | Directory listings and predictable temporary filenames |
| Download result | Check ownership or permission and use a controlled response path | The complete output directory and unrelated generated files |
| Cancel job | Verify authorization and transition the job through a defined cancellation process | General worker termination and process-management interfaces |
Prerequisites and decisions to make before exposure
This guide is intentionally implementation-neutral. No specific avatar project, installation command, default port, file path, environment variable, or credential format was supplied. Use the documentation for your selected avatar application to install it and identify its supported HTTP interface. Do not copy a port from an unrelated project or assume that every avatar application exposes an API.
Before configuring Localtonet, confirm all of the following:
- The avatar service is installed and starts successfully on the host or private network.
- A browser interface, API gateway, or reverse proxy provides the public-facing HTTP boundary.
- You know the actual local IP address and port of that boundary.
- The device running the Localtonet client can reach that IP address and port.
- The gateway requires authentication before accepting uploads, starting jobs, reading status, or downloading results.
- Internal model, queue, database, storage, and GPU worker interfaces are not included in the public route set.
- Upload limits, job concurrency limits, retention rules, and storage capacity have been defined.
- You have non-sensitive test media and a low-cost test job for end-to-end verification.
Choose where the Localtonet client will run
The simplest arrangement places our client on the same machine as the public application gateway. If the gateway listens only on the loopback interface, a client on that machine may target the appropriate loopback address and application port.
The client may instead run on another device that can reach the gateway over a private network. In that design, the target must listen on an address reachable from that device, and the private network must permit the connection. Do not make an internal service listen on every interface merely as a troubleshooting shortcut. Restrict its private-network reachability to what the design requires.
Confirm the local service before involving a tunnel
Test the gateway from the Localtonet client device. Confirm that the landing page or health endpoint responds, authentication is enforced, a test upload succeeds, a small job can be created, status can be retrieved, and the result can be downloaded. If the local path does not work, creating a public tunnel will not repair the application.
Understand the tunnel lifecycle
Creating a tunnel does not mean it is running. It must be started, and it remains available only while the selected client device is connected and the tunnel is running. Sleep, shutdown, client termination, network loss, or stopping the tunnel can make the public endpoint unavailable.
First install, configure, start, and verify the avatar application according to that project's own documentation. Then add Localtonet as the remote-access layer. This separation makes failures easier to diagnose and prevents tunnel configuration from hiding an application problem.
Configure a narrowly scoped local gateway
The gateway is the most important security component in this design. It should expose a deliberately small public contract while translating accepted requests into private operations. It can be built into the avatar application or provided by a separate web service or reverse proxy, but its behavior should be reviewed before public exposure.
Define an explicit route allowlist
List the routes remote users need. A typical design may require a login or token-validation route, upload creation, job creation, job status, preview retrieval, result download, and cancellation. The exact route names depend on the application and should not be invented from this guide.
Deny or omit administrative routes, model-management endpoints, queue dashboards, interactive debuggers, metrics containing sensitive details, unrestricted file browsers, development consoles, and general-purpose proxy behavior. If a bundled interface cannot hide those functions, place a restrictive gateway in front of it rather than publishing the bundled server directly.
Use asynchronous job semantics
Keep the request that creates a job short. Once validation succeeds and the job is durably recorded or queued, return its identifier. The client can retrieve state separately. This avoids coupling a potentially long GPU render to one network connection and gives the application a clear place to implement retries, cancellation, queueing, and failure reporting.
Job creation should be idempotent where accidental retries would otherwise duplicate expensive work. One common design is for the client to submit a unique request identifier within its authorized scope. The server can return the existing job for a repeated request rather than starting another render. The precise mechanism belongs to the application, not to the tunnel.
Control concurrency and cost
An authenticated user can still overload a GPU. Set limits for active uploads, queued jobs, simultaneous renders, output duration, dimensions, frame count, input count, and storage consumption according to the capabilities of the local system. Reject excess work predictably rather than allowing the operating system or GPU runtime to fail under pressure.
Separate admission from execution. The gateway should decide whether a request is allowed before the worker allocates expensive resources. Queue limits should be finite, and clients should receive a clear response when capacity is unavailable.
Design safe failure responses
Public error messages should explain what the user can correct without leaking internal paths, stack traces, environment variables, model locations, dependency versions, worker addresses, or secrets. Store detailed diagnostics in protected local logs and associate them with a request or job identifier that operators can search.
Handle callbacks carefully
If the application supports completion callbacks or webhooks, do not let arbitrary users make the GPU host request any destination without validation. User-controlled callback URLs can create server-side request forgery risk. Restrict destinations, resolve and validate addresses safely, or disable callbacks when polling is sufficient.
Secure uploads, jobs, previews, and downloads
Public AI media endpoints combine several high-risk characteristics: large request bodies, complex decoders, long-running compute, personally sensitive content, and expensive output generation. Security must cover both unauthorized data access and resource abuse.
Require authentication and object-level authorization
Authentication answers who is making the request. Authorization answers whether that identity may perform the requested action. Apply both to every sensitive operation. A user allowed to create a job should not automatically be allowed to inspect every job on the server.
Use opaque, non-sequential identifiers for jobs and media, but do not treat opacity as authorization. Every status, preview, cancellation, and download request should verify ownership, project membership, role, or another explicit access rule.
Keep credentials out of URLs because URLs can appear in browser history, logs, analytics, and referrer data. Never embed Localtonet device tokens in examples, frontend code, shared screenshots, or public repositories. A Localtonet auth token identifies the client device and must be kept secret.
Validate media beyond the filename
File extensions and client-provided content types are hints, not proof. Apply a supported-format allowlist, inspect the content using a safe method appropriate to the application, reject malformed structures, and process files with maintained libraries. If the pipeline invokes external media tools, pass structured arguments safely rather than constructing shell commands from user input.
Consider limits on compressed and expanded size, dimensions, frame count, duration, channel count, archive contents, and metadata. A small compressed input can expand into a much larger in-memory or on-disk representation.
Prevent path traversal and filename collisions
Generate internal storage names and keep uploads within a dedicated root. Normalize and validate any path before use, and reject attempts to escape the intended directory. Do not let a request overwrite model files, configuration, logs, another user's upload, or an existing result.
Use separate locations or namespaces for incoming uploads, validated inputs, working files, previews, final results, and quarantined failures. This separation makes cleanup and permission enforcement easier.
Set request and time limits
Apply maximum request-body sizes, upload time limits, header limits, and sensible idle timeouts at the gateway. These values must be selected for the expected media workload. A limit appropriate for a portrait-image generator may be unusable for source-video processing, while an unlimited body size creates unnecessary exposure.
Long inference duration should be handled by the job system, not by setting every HTTP timeout to an extreme value. Keep upload, job creation, status, preview, and download operations separate so each can have behavior appropriate to its purpose.
Protect generated and source media
Treat source and generated assets as private unless the service is intentionally public. Use least-privilege filesystem permissions. Avoid writing sensitive media into a directory served without authorization. Define retention periods and expose deletion controls when appropriate.
Logs should record enough information to investigate failures and abuse without copying credentials, full request bodies, personal scripts, or sensitive media into general-purpose log streams. Review what the web framework, reverse proxy, and application log by default.
Control cross-origin browser access
If a browser frontend and API use different origins, configure cross-origin access narrowly. Do not permit every origin with credentials merely to make development easier. Allow only the expected frontend origins, methods, and headers. If the frontend and API share one public origin, the architecture may be simpler, but application authentication and request-forgery protections are still required.
Development servers and debug interfaces may reveal stack traces, source code, environment details, or interactive execution features. Use the avatar project's documented production configuration and place a controlled gateway in front of internal components. Because no specific project was supplied, this guide cannot safely prescribe a production command or assume a default server.
| Risk | Gateway control | Operational control |
|---|---|---|
| Unauthorized generation | Authentication, authorization, and scoped API access | Review access and revoke credentials when no longer needed |
| GPU exhaustion | Finite queues, concurrency limits, quotas, and input constraints | Monitor queue depth, render duration, memory, and failures |
| Storage exhaustion | Upload limits and per-user or per-project quotas | Retention policies and cleanup for every terminal job state |
| Malicious media | Format allowlists, structural validation, and safe decoder use | Patch media libraries and isolate processing where practical |
| Cross-user data access | Object-level checks on jobs, previews, and downloads | Audit authorization failures without logging sensitive content |
| Information leakage | Sanitized errors and protected administrative routes | Restrict logs, backups, temporary files, and diagnostics |
Expose the gateway with a Localtonet HTTP tunnel
Once the local gateway works and the security boundary is ready, add remote access. Our client establishes an outbound connection to a Localtonet relay server. The resulting HTTP tunnel provides a public address for the selected local IP address and port without requiring inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
HTTP tunnels support the Process Type choices Random Sub Domain, Custom Sub Domain, and Custom Domain. These choices serve the same content at a public HTTPS address. Availability can vary, and custom-domain DNS requirements must be checked against current documentation before making DNS changes. Do not assume that every option is included in every plan.
Install and run the Localtonet client
Install our client for the operating system on a device that can reach the avatar gateway. Run it using the current installation and authentication workflow shown by Localtonet. This article does not invent a client command because installation details can vary by operating system and client version.
Authenticate and select the client device
Use the device-specific auth token associated with the client that will run the tunnel. Keep the token private. Never paste it into frontend code, logs, public issue reports, screenshots, or a shared article.
Select an available relay server
Choose a server or region from the current Localtonet dashboard. Available server codes and regions can change and may vary by plan, so obtain the value from the product rather than copying a hardcoded example.
Create the HTTP tunnel configuration
Select the required Process Type and point the tunnel to the actual local IP address and port of the protected avatar gateway. Do not target the GPU worker, queue dashboard, database, unrestricted model API, or temporary-file server. Confirm any custom-domain DNS requirements against the current documentation before using that option.
Start the tunnel
Use the Start button after reviewing the target. Creating the configuration alone does not make the tunnel active. The selected client must remain connected and the tunnel must remain running.
Use and verify the assigned public address
Open the assigned public URL from an external connection and complete the verification plan below. When access is no longer required, stop the tunnel. Delete obsolete tunnel configurations when they should not be reused.
For the current product workflow, consult the Localtonet HTTP tunnel documentation while configuring the tunnel. Exact dashboard availability, relay choices, domain behavior, and plan-specific options should always be confirmed in the current product.
A target that works from your laptop may still be unreachable from the device running our client. Test the avatar gateway from the client device itself. If the client and gateway are on different machines, verify the private address, listening interface, local firewall policy, and network route.
Verify the complete remote workflow
A successful landing page proves only that one route can respond. Avatar services need an end-to-end test that exercises authentication, upload handling, asynchronous generation, progress, preview delivery, downloads, cleanup, and failure behavior.
Run a local baseline first
Before testing the public URL, perform the same workflow against the local gateway from the Localtonet client device. Record what success looks like, including expected response states and approximate resource behavior. Use non-sensitive test media and a small job that does not consume unnecessary GPU time.
Test from outside the local network
Use a device or network that is not relying on the same local route. Open the assigned public address and confirm that unauthenticated access is rejected where expected. Then authenticate using a test account with the minimum required permissions.
Exercise each workflow stage
- Upload one valid test asset and confirm that it receives an opaque identifier.
- Attempt a disallowed type and confirm that validation rejects it safely.
- Attempt an oversized request and confirm that the gateway returns a controlled response.
- Create one inexpensive job and verify that duplicate submission behavior is understood.
- Read job status until the job reaches a terminal state.
- Open a preview and confirm that another unauthorized account cannot retrieve it.
- Download the result and check its content and media type.
- Test cancellation if the application supports it.
- Confirm that expired or deleted assets are no longer retrievable.
Test negative authorization cases
Create jobs under two separate test identities if the application supports multiple users. Verify that changing a job or media identifier does not expose another user's status, preview, result, or cancellation action. Test both predictable mistakes and deliberately altered identifiers.
Test interruption and recovery
Stop the tunnel while a private worker is processing a job. The public client should lose access, but the result inside the private system depends on the application's job semantics. Restarting the tunnel does not automatically guarantee that an interrupted browser request will resume. The client should query the job again after connectivity returns.
Also test a Localtonet client restart, a gateway restart, a failed render, a full queue, insufficient storage, and invalid input. The application should return controlled states rather than leaving jobs permanently marked as running.
Observe resource behavior
During testing, inspect CPU, GPU memory, system memory, disk usage, temporary storage, queue depth, and generation duration. Verify that one user cannot create an unbounded number of jobs or simultaneous uploads. Confirm that cleanup occurs after success, failure, cancellation, and expiration.
Avatar inputs and results may contain personal likenesses, voices, or confidential content. Use media you are authorized to process and share. Technical access controls do not replace consent, licensing, disclosure, or other obligations applicable to the deployment.
Operate and troubleshoot the service
Remote access is reliable only when the application, gateway, worker, storage, Localtonet client, and tunnel lifecycle are operated as one system. Monitoring should distinguish a public connectivity failure from a local gateway failure or an inference failure.
Monitor separate health layers
A useful health model has at least four layers:
- Public reachability: Can an authorized external test reach the assigned public address?
- Gateway health: Can the Localtonet client device reach the local IP address and port?
- Dependency health: Can the gateway reach its private queue, storage, database, and worker?
- Inference health: Can a controlled test job complete without exhausting resources?
Keep health responses minimal. A public health route should not reveal internal hostnames, model paths, GPU details, dependency versions, queue contents, or environment configuration.
The public address does not respond
Confirm that the selected Localtonet client is connected and that the tunnel is running. Remember that creating the tunnel is not the same as starting it. Check whether the host is sleeping, shut down, disconnected, or running the client under a user session that has ended.
Next, test the local gateway from the client device. If that fails, confirm the target IP address, target port, listening interface, process state, and private-network route. A connection-refused error generally points to no service listening at the chosen destination, while a timeout can indicate routing, firewall, or an unresponsive process. Interpret exact errors in the context of the operating system and application.
The interface loads, but jobs fail
If basic HTTP routes work, the tunnel has reached the gateway. Investigate the private application path: request validation, queue insertion, worker availability, model loading, GPU memory, input decoding, storage permissions, and output creation. Do not solve an internal worker problem by exposing the worker publicly.
Uploads fail or stop partway through
Compare the attempted file with application-level body-size, duration, and format limits. Check available temporary storage and gateway logs. If a reverse proxy or framework sits in front of the application, it may have its own request limit or timeout. Change limits deliberately and keep a finite ceiling rather than disabling every protection.
Generation completes, but download fails
Verify that the job record points to the expected result and that the gateway process has permission to read it. Confirm that authorization succeeds for the correct user, the file still exists, cleanup did not run too early, and the response does not expose an invalid internal path. Test the same download locally before blaming the public tunnel.
Progress updates do not appear
Determine how the application transports updates. Polling, server-sent events, WebSockets, and custom media transports have different connection behavior. If polling works but a persistent update channel does not, review the application's protocol and connection requirements. Current Localtonet compatibility for the exact mechanism should be verified rather than assumed.
Requests are duplicated after a retry
Network interruptions can cause clients to retry without knowing whether the original job was accepted. Use application-level idempotency or a safe lookup mechanism for expensive job-creation requests. The tunnel forwards traffic, but it does not define duplicate-submission semantics for the avatar application.
Storage usage keeps increasing
Inspect abandoned uploads, failed decoder output, extracted frames, cancelled jobs, preview caches, completed results, and logs. A cleanup process that handles only successful jobs is incomplete. Use explicit retention states and verify cleanup with automated tests.
| Symptom | First check | Likely layer |
|---|---|---|
| Public URL unavailable | Client connection and tunnel running state | Localtonet lifecycle or host connectivity |
| Public and local target both fail | Gateway process, IP address, port, and listener | Local application or private network |
| Login works, generation fails | Queue, worker, model, GPU, and storage logs | Private inference stack |
| Small uploads work, large uploads fail | Request limits, timeouts, disk capacity, and format checks | Gateway or application configuration |
| Other users can read a job | Object-level authorization on every job route | Application security |
| Jobs duplicate after reconnect | Job-creation idempotency and client retry behavior | Application protocol |
Plan separately for real-time and interactive avatars
Batch avatar generation maps naturally to HTTP: upload media, create a job, poll status, and download a result. A real-time avatar may have a different media path involving persistent sessions, bidirectional control, continuous audio, continuous video, or application-specific raw TCP or UDP traffic.
Do not choose a tunnel based only on the fact that the control page opens in a browser. Inspect the protocol used for the actual media path. Developer tools, application documentation, server configuration, and packet-level observation in an authorized environment can help identify whether the system uses ordinary HTTP requests, a persistent browser protocol, raw TCP, UDP, or a combination.
| Workload component | Possible network pattern | Planning guidance |
|---|---|---|
| Upload and job creation | Ordinary HTTP requests | Use an HTTP gateway and enforce authentication, validation, and limits |
| Status polling | Repeated short HTTP requests | Keep responses small and apply sensible polling intervals |
| Persistent progress channel | Long-lived HTTP-derived connection | Test the exact application behavior and current tunnel compatibility |
| Result delivery | HTTP media download | Authorize every object and define caching and retention behavior |
| Interactive media stream | Application-specific TCP, UDP, or multiple flows | Document every required flow before selecting tunnel types |
| Private worker control | Internal HTTP, TCP, queue, or process interface | Keep private and reach it only through the gateway or trusted internal network |
Localtonet supports HTTP/s, TCP, UDP, TLS, and combined UDP/TCP tunnel families. This does not mean that every real-time avatar system will work by opening each observed port. Interactive protocols may negotiate addresses dynamically, require multiple related flows, depend on browser behavior, or include their own authentication assumptions.
Start with an inventory: protocol, direction, local address, local port, session lifetime, authentication method, and whether the flow contains public user data or private control traffic. Expose only the minimum public flows. Keep administrative and worker-control paths private even if they use the same protocol family as public media.
An HTTP tunnel is appropriate for a verified HTTP interface. If the avatar's live audio or video path uses raw TCP, UDP, combined transport, or another specialized protocol, plan that path separately and confirm current Localtonet options in the dashboard and documentation. Do not expose additional ports speculatively.
Frequently asked questions
Can I expose a self-hosted AI avatar service without router port forwarding?
Yes. The Localtonet client establishes an outbound connection to our relay server, and an HTTP tunnel can provide a public address for a local avatar gateway. This does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The client must remain connected and the tunnel must be running.
Should I point the tunnel directly at the model server or GPU worker?
Usually no. Point the tunnel at a narrowly scoped application gateway that authenticates users, validates uploads, enforces quotas, creates jobs, and authorizes previews and downloads. Keep unrestricted model controls, worker interfaces, queues, databases, storage services, and debugging tools private.
Does creating a Localtonet tunnel start it automatically?
No. Creating a tunnel configuration does not mean it is running. Start it with the Start button. The selected device must be connected, and the tunnel remains available only while the client is connected and the tunnel is running.
Does an HTTP tunnel authenticate users of my avatar API?
The tunnel provides connectivity to the configured target. Your gateway must enforce application authentication and authorization. Protect upload, job, status, preview, cancellation, and download operations, and verify object-level access on every request.
How should long-running avatar generation requests work?
Prefer an asynchronous workflow. Validate the request, create and enqueue a job, return an opaque identifier, and let the client query status separately. This avoids holding one request open for the entire render and gives the application clearer retry, cancellation, queue, and failure semantics.
Can Localtonet expose an avatar service running on another machine?
The HTTP target may be on or reachable from the device running our client. If it is on another private machine, the client device must be able to reach the selected IP address and port. Configure private listening addresses, routes, and firewall rules according to least privilege.
Which port should I use for my self-hosted avatar application?
Use the port configured by your actual gateway or avatar project. There is no universal AI avatar port, and none can be safely inferred here. Verify the application's configuration and test that exact address from the Localtonet client device before creating the tunnel.
Is an HTTP tunnel enough for a real-time talking avatar?
It depends on the application's actual media path. Uploads, job creation, polling, and downloads commonly fit HTTP. Interactive audio or video may use persistent browser connections, raw TCP, UDP, combined flows, or another protocol. Inspect and document the implementation, then choose the minimum suitable tunnel type and test it end to end.
What happens to a running generation job if the tunnel stops?
Public access stops when the tunnel or selected client is no longer running. Whether an already queued or running generation continues is determined by the local avatar application's job system. A robust client should reconnect later and query the job state instead of assuming that the original request remains active.
Can I use a custom domain for the avatar interface?
HTTP tunnels have Random Sub Domain, Custom Sub Domain, and Custom Domain Process Types. Availability may vary, and exact custom-domain DNS requirements must be checked against current Localtonet documentation and the dashboard before configuration. Do not copy unverified DNS values from another deployment.
Publish your protected avatar gateway with Localtonet
Verify the avatar workflow locally, keep the model runtime and GPU worker private, then create an HTTP tunnel to the narrowly scoped gateway. Start with test media, minimum privileges, finite resource limits, and a clear shutdown and retention plan.
Get Started Free →
