Install Zealot and Enable Remote Access with Localtonet

How Zealot and Localtonet fit together

Zealot organizes beta application distribution around a self-hosted web service. Its version 6.2.2 user guide describes Android APK and AAB support alongside iOS, macOS, Windows, and Linux applications. It also documents application channels, a REST API, Android and iOS SDKs, fastlane integration, and notifications through webhooks. These capabilities let teams organize release streams rather than distribute each build through email or chat.

Distribution involves several different clients. Testers open release pages and retrieve packages. CI runners upload new builds. Applications integrating a Zealot SDK can check for updates. Identity providers and notification services may introduce additional network dependencies. A working browser page is therefore only the beginning of an acceptance test, not proof that the entire workflow is ready.

With Localtonet, our client establishes an outbound connection to a relay server and makes the selected local web endpoint available at a public HTTPS address. This does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address. The network must still permit the necessary outbound connection, and you must have permission to publish the service.

Ordinary HTTP tunneling is not a private mesh VPN. If your requirement is that clients join a private network rather than reach a public web endpoint, evaluate that architecture separately. Our VPN Manager is the actual private mesh VPN feature.

Establish deployment readiness before publishing anything

For a new installation, obtain the complete release-matched procedure from the official Zealot self-hosted guide and deployment files maintained by the official Zealot project. Do not substitute a repository's moving development branch for a release-matched deployment without reviewing compatibility. The supplied release page confirms that 6.2.2 exists, but it does not establish that this is the release you should deploy today.

Zealot promotes Docker deployment. That fact alone does not establish a supported Compose command, dependency topology, image tag, or resource minimum. Similarly, the user guide contains the architecture string amd86/arm64. Because that wording is ambiguous and no image manifest is available here, we do not normalize it into an amd64 compatibility claim. Confirm the selected image's platform metadata and the architecture support of every dependency before choosing a host.

Build a deployment handover record

The person installing Zealot should provide a compact operational record before remote access is enabled. Record actual values from the deployment, not plausible defaults. Keep secret values in your secret manager and record only how an authorized operator retrieves them.

Size storage around retained artifacts

Plan capacity around the builds you retain, not only the application container. Include packages, debug files, operational data, backups, and temporary space required by your deployment. The official evidence here establishes no minimum CPU, memory, or disk requirement. Measure your own workload and use any release-specific recommendations supplied by the project.

A disposable container filesystem is not durable storage. A successful restart is also not proof that a backup can restore the service. Keep those two acceptance criteria separate: persistence proves that expected data survives routine operation; restoration proves that you can recover after losing the original installation.

Choose the Localtonet client location

Our client must run where it can reach Zealot's published endpoint. If both programs run in the same host network context, a loopback target may work. If they run on separate machines, use the reachable private address of the Zealot host. A client running inside a container has its own network context, so 127.0.0.1 generally refers to that container, not the host or another container.

Publish only the web endpoint needed by testers and automation. Do not expose dependency services, container-management interfaces, storage administration, or unrelated host ports as part of this workflow.

Define the distribution acceptance test

Before remote access, agree on one small test scenario: an authorized uploader adds a non-sensitive package to an intended application and channel, and an authorized tester retrieves it. The supplied evidence confirms channels and team-management capabilities but not the exact application-creation screens, permission matrix, or account initialization sequence. The checks below describe required outcomes, not invented Zealot menu instructions.

Prepare one application and one channel

Using the controls documented for your installed release, establish a clearly labeled test application and channel. Use a package that is safe to share during evaluation. Confirm that its displayed application identity, version, platform, and release notes match what you uploaded. Avoid starting with multiple channels because a misplaced package becomes harder to distinguish from an access problem.

A channel name is an organizational label, not proof of isolation. Test whether an account outside the intended audience can discover the application, view release information, or retrieve the package. Record the actual result and decide whether it satisfies your policy.

Validate authentication before enabling integrations

Zealot's 6.2.2 guide lists Google, GitLab, GitHub, LDAP, OIDC, and Lark authentication integrations. Availability does not mean any particular provider is enabled or correctly configured on your server. Start with the sign-in method already established for your deployment. If you add an identity provider, verify its release-specific settings and callback requirements separately.

Use separate administrator, uploader, and tester identities where the installed release supports your required separation. This is a least-privilege recommendation, not a claim that Zealot implements particular built-in roles or token scopes. Verify the actual permissions available before promising that a credential is channel-limited or read-only.

Prove manual upload and download first

Upload the test package through your installed release's supported manual workflow. Then sign in using the intended tester identity and download it. Also test a signed-out browser session against both the release page and the direct download link. If anonymous downloads are intentional, document that decision; otherwise, treat unexpected anonymous access as a blocker.

Successfully downloading a package does not prove it can be installed. In particular, AAB support does not mean an AAB behaves like a directly installable APK, and an HTTPS page alone does not satisfy iOS signing, provisioning, manifest, device eligibility, or Apple policy requirements. Validate the complete installation path on the actual target device.

Verify the existing service locally

Test from the Zealot host first, then from the device running our client. Use the endpoint recorded in the deployment handover. Do not guess a default port or assume that a container's internal port is published on the host.

Check HTTP reachability

If curl is installed, the following Bash example requests the root page and prints response headers without saving the body. Enter your actual local URL when prompted, including its scheme and published port. This is a general HTTP diagnostic, not a Zealot health-check endpoint.

read -r -p "Verified local Zealot URL: " ZEALOT_LOCAL_URL
curl --connect-timeout 10 --max-time 30 \
  --dump-header - --output /dev/null \
  "$ZEALOT_LOCAL_URL"

An expected page response or login redirect establishes basic HTTP reachability. A redirect to an unreachable hostname needs investigation. A connection refusal suggests the address or port has no reachable listener; a timeout may indicate a routing or filtering problem. Even a successful HTTP response does not prove that authentication, uploads, or storage work.

Complete the browser checks

1. Open the same endpoint in a browser and inspect the page for missing assets, server errors, or redirect loops.
2. Sign in with the intended account and complete the test upload.
3. Retrieve the build as a tester and confirm the package is the expected file.
4. Test signed-out access and any access boundaries required by your policy.
5. Repeat access from the Localtonet client device to prove that device can reach the service.
6. During a planned maintenance window, use the deployment's supported restart procedure and confirm that records and artifacts remain available.

Inspect the deployment's service logs while testing. Look for repeated restarts, initialization failures, permission errors, storage failures, and unsuccessful dependency connections. No release-matched service names or log commands are established here, so use the operational record rather than a guessed container command.

Enable remote access with Localtonet

Use an HTTP tunnel for the Zealot browser interface and HTTP API. The following steps describe our supported connection lifecycle, not a claim about the exact order of fields in the current dashboard. For current screen-specific instructions, use the Localtonet HTTP tunnel documentation. Interface details and available options can vary by client version and plan.

Repeat acceptance testing from outside the private network

Use a phone on mobile data or another authorized external connection. Open the public HTTPS URL, sign in as a tester, view the intended release, and download the non-sensitive package. Repeat the signed-out tests. Check that generated links do not send the tester to a private IP address, localhost, or an unexpected hostname.

Test both the release page and the artifact request. A page can load successfully while its download link uses a different address or encounters an application error. Record the time of a failed request so you can correlate it with application logs without recording passwords or session cookies.

Add optional CI, SDK, and notification integrations

None of these integrations is required to prove remote browser access. Add them only after manual upload and download succeed. This keeps a failed build pipeline or callback configuration from obscuring a healthy base service.

CI uploads

Zealot's version 6.2.2 best-practices guide shows fastlane workflows using fastlane-plugin-zealot, with endpoint, token, and channel_key values supplied to the zealot action. It also shows optional debug-file workflows for iOS dSYM and Android Proguard-related files.

Configure these in an existing, working fastlane project using the plugin version and settings appropriate to your deployment. The supplied evidence does not include a complete plugin installation procedure or credential-creation workflow, so this article does not present an incomplete snippet as a runnable CI setup.

Store tokens and any sensitive channel keys in your CI secret store. The endpoint is configuration rather than necessarily a secret, but it can still reveal internal distribution infrastructure. Keep credentials out of source code and job output. Verify the credential's actual permissions instead of assuming it can be restricted to a single channel.

SDKs and webhooks

Zealot documents SDK-based update checks, change-log display, and installation-related functionality. Its configured application webhook can notify another service when a new build is received. Test update discovery and notification delivery separately from package upload.

These are distinct from our Token/Tunnel status webhooks, which report Connected or Disconnected changes for tokens or tunnels in a selected Token Group. A tunnel connection event does not prove that a Zealot upload succeeded, and a connected client does not prove application health.

Public URL stability

CI settings, tester bookmarks, SDK configurations, and identity-provider callbacks can depend on the public address. Before broad rollout, choose an available address option that meets those needs. If the hostname changes, update affected integrations and retest them. Verify custom-domain availability and current DNS instructions rather than assuming a generated address is permanent.

Operate securely and prepare for recovery

A distribution server can contain executable packages, debug symbols, release notes, user information, and integration secrets. Treat it as an operational service even if every build is labeled beta. Assign an owner for access reviews, storage monitoring, updates, and recovery testing.

Protect accounts and credentials

Avoid sharing an administrator identity across testers and automation. Remove unused accounts, review access after team changes, and revoke exposed credentials. Packages themselves can contain configuration or sensitive identifiers, so inspect the test artifact before assuming it is harmless. Never embed administrator or unrestricted upload credentials in a distributed application.

Back up a coherent recovery set

The supplied evidence does not establish Zealot's exact backup paths, database procedure, or restore order. Do not treat a guessed volume copy as a verified backup. Use the deployment's documented procedure to identify all persistent application state, uploaded artifacts, required configuration, and secrets needed for recovery.

Record which release produced each backup and whether writes must be paused for consistency. Restore into an isolated environment with compatible software, then verify accounts, application records, channels, and package retrieval. Prevent a recovery test from unintentionally sending real notifications or accepting production uploads.

Restart, shut down, and upgrade deliberately

For planned maintenance, notify testers, pause automated uploads, and stop the public tunnel if access should be unavailable. Use the release-matched deployment procedure for application shutdown and startup. Do not substitute commands that remove persistent volumes for a routine stop.

Before an upgrade, preserve the deployment definition and verify a usable recovery backup. Review the target release's migration instructions and compatibility requirements. A rollback may require restoring data as well as selecting the older image; changing an image tag alone is not a safe general rollback strategy after data migrations.

After maintenance, repeat local sign-in, upload, download, and persistence checks. Start the tunnel only when the local service passes, then repeat an external tester check. Monitor the application, client connection, and tunnel state as separate layers.

Troubleshoot one layer at a time

The page does not open locally

Leave the tunnel out of the investigation. Check the deployment's required services and logs, then verify the published address and port. A listener available only inside a container network may not be reachable from the host or our client. Correct the network publication using the deployment's supported configuration.

The local page works, but the public URL does not

Confirm that the selected client is connected and that the tunnel was started. Repeat the local request from the client device, not only from the Zealot host. Recheck the local target, especially if it uses loopback or the host address has changed.

The page loads, but assets, redirects, or download links fail

Inspect the failed request's destination and response. Private hostnames or incorrect schemes can indicate external URL or proxy configuration problems. Consult the deployed release's settings for the applicable fix; no verified Zealot environment-variable names are established here. Do not disable security checks merely to suppress a redirect or origin error.

Identity-provider login fails

Compare the public scheme, hostname, callback path, and provider registration with the release-specific configuration. A hostname change can invalidate a previously working callback. Test with a non-privileged account after correcting the configuration.

A CI upload fails while browser access works

Check runner connectivity, endpoint configuration, credentials, destination channel, and application logs. A browser login does not validate an API credential. For large uploads, investigate storage and timeout behavior without assuming an undocumented Zealot or Localtonet size limit.

Builds disappear after a restart

Pause uploads and investigate persistence. Check whether records and artifacts were written to the expected durable storage and whether that storage is mounted correctly. A missing mount can resemble deletion, so avoid destructive recovery actions until you identify where the data resides.

Remote access stops unexpectedly

Check Zealot health, client connectivity, and tunnel state independently. Also check host sleep, power, and private-network reachability. A running tunnel cannot serve an application that has stopped, and a healthy local application is not publicly available through a disconnected client.

Frequently asked questions