Install Conduit and Test APIs with Localtonet

How Conduit and Localtonet fit together

ConduitPlatform coordinates specialized backend modules through a shared core. Its current website describes authentication, database, storage, authorization, communications, chat, functions, and a Router that provides REST, GraphQL, and realtime integration surfaces. The modules enabled in your deployment determine which capabilities your application can actually use.

A local backend and a publicly reachable backend solve different problems. A phone using cellular data, a hosted test runner, or an external webhook provider cannot reach your computer through its loopback address. Even on the same Wi-Fi network, localhost on a phone refers to the phone, not your development computer.

With Localtonet, our client establishes an outbound connection to a relay server. An HTTP tunnel maps a public HTTPS address to an HTTP service on or reachable from that client device. You do not need inbound router port forwarding, firewall changes, VPN setup, or a public IP address. You still need permission to use the network and expose the application.

The tunnel does not install Conduit, start its modules, create API routes, or add missing authorization. Conduit must work locally first. Our client must then be able to reach the same listener that passed local verification.

This guide concerns ConduitPlatform/Conduit. Other products called Conduit have unrelated SDKs, credentials, and API paths. In particular, a documented endpoint from an email service, media-analysis service, or RealWorld example application is not evidence of a ConduitPlatform endpoint.

Check prerequisites without importing legacy assumptions

The current command uses npx, so running it requires a Node.js environment with npm/npx available. That identifies the tooling family, not a supported minimum Node.js version. The available current material does not establish a Node.js support range, npm version, Docker version, Compose version, operating-system matrix, or required privilege model for this CLI workflow.

Do not infer those requirements from another Conduit project or from the retired bootstrap instructions. A command that starts successfully can still fail later because its runtime or deployment environment is unsupported.

These general tool checks report what is installed; they do not prove that the versions satisfy Conduit's requirements:

node --version
npm --version
npx --version

If any executable is missing, configure the supported runtime and toolchain before running setup. Do not use an arbitrary runtime version simply because it is already present. Do not add elevated permissions as a general response to installation errors.

If the deployment instructions for your selected release require Docker and Compose, the following standard Docker diagnostics help distinguish a missing client, missing Compose plugin, and unavailable daemon:

docker --version
docker compose version
docker info

These are Docker checks, not verified Conduit prerequisites or startup commands. Review daemon-access failures with the host's administrator instead of broadly changing socket permissions. On Windows, neither a universal WSL requirement nor universal native support is established by the current evidence.

For the later tunnel workflow, you need a Localtonet account, our client on a device that can reach the application, permission to expose the development service, and a non-production test identity. A browser and an HTTP client such as curl are useful for inspecting responses.

Use Conduit's current CLI entry point

The current ConduitPlatform website presents this local setup command:

npx @conduitplatform/cli deploy setup

Use it only after confirming the release-specific prerequisites. It replaces the legacy bootstrap-first instruction in this article. Do not combine it with the older shell bootstrap or run several deployment methods against the same working directory and data.

The command shown on the website is not version-pinned. Record the CLI version actually used and the deployed Conduit version for reproducibility. The website's announcement that v0.17 documentation is live does not prove which package or deployment version an unpinned command will resolve at execution time.

Run setup in an authorized development environment under an account with only the permissions the supported workflow needs. Package execution can download and run code. Review the package identity and your organization's software-installation policy before approving execution.

What this command does not establish

The supplied current page does not document the complete prompt sequence, output files, automatic browser behavior, initial administrator credentials, or a separate start command. We therefore do not promise that a browser opens automatically, that a particular port is selected, or that a universal administrator username and password will work.

Nor can we claim that returning from this command means every service is healthy. Installation, process startup, dependency readiness, and application readiness are separate checkpoints. A setup banner is not a substitute for checking the deployed listener and a real application response.

Keep alternative deployment paths separate

Conduit's current site advertises Docker Compose, Kubernetes/Helm, and running from source. Those are distinct deployment choices, not interchangeable continuations of this command. Their current manifests, build dependencies, configuration files, and lifecycle instructions are not established in the material available for this revision, so they are outside the implementation scope here.

The ConduitPlatform repository identifies the intended project. When preparing a release-specific runbook, use material for the selected release rather than assuming the repository's current branch, an older release, and the current CLI all describe the same deployment.

The handoff required before tunnel configuration

Proceed to remote exposure only when your deployment has an independently verified local baseline containing:

• The installed CLI and application versions.
• The administration URL and the separate Router origin, or explicit confirmation that they share a listener.
• The listener address reachable from the Localtonet client device.
• A documented, non-mutating HTTP request with its method, path, authorization requirements, and expected response.
• A supported way to inspect service status and logs.
• Known stop, restart, storage, backup, update, and recovery procedures.

This is a readiness gate, not a replacement for missing installation instructions. If these details are unavailable, keep the deployment private and resolve them before continuing.

Verify the local listener and application separately

A useful verification sequence separates service health, HTTP reachability, and endpoint correctness. A loaded dashboard shows that its listener responds. It does not establish that the Router uses that listener or that database, authentication, and storage dependencies are ready.

Identify both addresses

Keep the administration address and application Router origin in separate entries in your deployment notes. For each, record the scheme, hostname or IP address, port, and any documented path prefix. No exact current Conduit dashboard or Router address is established by the available installation material.

For tunnel targeting, consider the network namespace of our client. Loopback on a host, inside a container, and inside a virtual machine can refer to different environments. A container's internal listening port is not necessarily the host-published port. Test from the device and environment where the Localtonet client actually runs.

Establish a documented safe request

The available ConduitPlatform evidence does not supply a release-matched harmless API endpoint or health route. Accordingly, this guide does not invent /health, a ping path, a Swagger URL, or an authentication endpoint. It cannot provide a copy-and-run Conduit health request until that route is known.

For an already configured deployment, select a documented read-only request with a known response. Prefer disposable test data and the least-privilege identity needed for that route. Do not assume that an arbitrary GET path is harmless merely because its HTTP method is GET.

The following is a general diagnostic template, not a Conduit endpoint example. Replace the placeholder with the complete verified URL. Add authentication only according to the endpoint's documented mechanism:

curl --silent --show-error --include --max-time 15 \
  'REPLACE_WITH_VERIFIED_LOCAL_READ_ONLY_URL'

This command displays response headers and body, limits the wait to 15 seconds, and does not automatically follow redirects. It deliberately leaves HTTP error responses visible for diagnosis. A curl process completing does not mean that the API returned its expected status or data.

Check the status, content type, body, and any redirect destination. HTML from a dashboard is not a successful JSON API response. A 401 may demonstrate that a listener was reached, but it does not complete an authorized read test. A service-status check and a successful application request together provide stronger evidence than either alone.

Secure the service before public exposure

A public HTTPS address provides reachability and HTTPS for remote requests. It is not application authorization. Review every route accessible through the selected listener, not only the one you plan to share.

• Secure administration: complete the installed release's account setup and replace any initial or shared credentials. Do not assume admin/admin is a valid current login.
• Use least privilege: test mobile requests with application identities, not platform administrator credentials.
• Minimize exposed functionality: prefer the application Router over a management listener when the deployment separates them. Protect any administration routes reachable on the same listener.
• Use development data: avoid exposing copied customer records, production secrets, or production storage accounts.
• Protect credentials: keep secrets out of URLs, source code, screenshots, issue reports, and shell-history examples.
• Bound the test window: stop the tunnel when testing ends and revoke temporary credentials when they are no longer needed.

A compiled mobile application cannot safely conceal a permanent administrator secret. Treat credentials embedded in a distributed test build as recoverable by its recipient. Use application authentication appropriate to the installed Conduit release and keep privileged operations server-side.

Create a Localtonet HTTP tunnel

Once a local HTTP request passes verification, use our HTTP tunnel family to expose that listener. An HTTP application does not need a raw TCP tunnel simply because HTTP uses TCP underneath. Available relay servers and options vary, so use the current dashboard rather than a hardcoded region or server code.

Our HTTP tunnel documentation supplements this workflow with the current product interface.

The local target fields identify the listener, not an entire API request. Keep the route path in the client request. Review redirects as well: an application redirect to a loopback address can send a remote browser to the wrong machine even when the initial tunnel request succeeds.

Test HTTP APIs and webhook delivery remotely

Repeat the baseline request through the tunnel

From a remote client, send the same read-only request used locally, replacing only the origin with the assigned public HTTPS origin. Preserve the documented path prefix, method, request headers, and query parameters. Do not place credentials in the query string.

curl --silent --show-error --include --max-time 15 \
  'REPLACE_WITH_PUBLIC_HTTPS_ORIGIN_AND_VERIFIED_READ_ONLY_PATH'

This is again a diagnostic template. Compare the meaningful status and response fields with the local result. Timestamps or request identifiers may differ. Only after this comparison passes should you test authorized writes with disposable records.

Configure physical mobile devices

Use the public HTTPS origin as the development API base URL. A phone should not use the computer's loopback address or an emulator-specific host alias. Keep development, staging, and production configurations separate so a temporary test URL cannot accidentally enter a production build.

If the public address changes after a tunnel is recreated, update the mobile configuration and restart or rebuild as required by the framework. Check for cached values when an emulator succeeds but a physical device fails. Never disable certificate verification as a connectivity workaround.

Distinguish browser policy from connectivity

CORS is primarily a browser-enforced policy. A successful curl request does not prove that browser JavaScript will be allowed to read the response. Inspect the browser's network panel for preflight requests, redirects, response headers, and authentication failures.

The origin that needs permission is the frontend application's origin, not automatically the API tunnel's own origin. Use the installed Conduit release's supported configuration mechanism. This guide does not establish a particular CORS setting name or configuration path. Avoid broad wildcard policies for sensitive or credentialed requests.

Deliver webhooks to an existing handler

Build the provider's callback URL from the tunnel origin plus a real, locally tested receiving route. The handler must already accept the provider's HTTP method, content type, payload, and signature scheme. Localtonet transports the request; it does not implement the handler.

Use the provider's test-delivery mechanism and inspect both its delivery result and your application's sanitized logs. Where signatures are supported, verify them according to the sender's documented protocol. Some schemes require the exact raw request body, so parsing and reserializing JSON before verification can change what is signed.

Plan for duplicate delivery. A timeout or failed acknowledgment can cause a provider to retry an event that the application already received. Use a stable event identifier or documented deduplication key, and avoid irreversible effects during development. Keep synchronous processing short enough for the provider's response deadline.

Application webhooks also differ from our platform-wide Token/Tunnel webhooks. Those notifications report Connected or Disconnected lifecycle changes for a selected Token Group. They do not carry Conduit application events. File Server file-event webhooks are a separate feature again.

Operate safely and troubleshoot one layer at a time

Know the maintenance boundary

The available current Conduit material does not establish exact stop, restart, update, log-inspection, backup, or recovery commands for the CLI-created deployment. It also does not identify its persistent volumes, database locations, or upload directories. Supplying generic Compose commands as though they were verified CLI instructions would risk operating on the wrong project or losing data.

Before relying on the installation, obtain a release-matched runbook that identifies the working directory, configuration files, project or service identifiers, status and log commands, and lifecycle procedures. Keep a sanitized copy alongside your development notes. Do not assume rerunning setup is a restart or an upgrade.

Persistence must cover every stateful component the selected modules use, including application records and uploaded files. Back up configuration and secrets through an appropriately protected process. Verify restoration in an isolated environment before treating a backup as a recovery path. Updates may involve schema changes, so replacing an image or package version is not automatically a reversible operation.

If recovery details are unknown, stop public exposure first, preserve available logs and configuration, and avoid deleting containers, directories, or volumes as a diagnostic shortcut. No destructive reset procedure is verified here.

Use a repeatable diagnostic order

1. Check application readiness with the deployment's supported status and log procedures.
2. Repeat the verified local HTTP request from the Localtonet client device.
3. Confirm the tunnel's local IP, port, selected device, and running state.
4. Repeat the same route through the public HTTPS origin.
5. Compare browser, mobile, or provider-specific behavior only after the basic HTTP request succeeds.

Change one layer at a time. Restarting everything immediately can remove useful evidence and make an intermittent failure harder to reproduce.

Connection refusal, timeouts, or gateway errors

Repeat the local curl template against the verified target. A connection refusal often means no listener is accepting connections at that address and port. A timeout can have several causes, including an unreachable target or a stalled application. Check the deployment's supported diagnostics rather than assuming either symptom is a tunnel fault.

If the request works from the browser on one machine but fails from our client device, compare network namespaces and addresses. If it works from our client device, check the configured target, selected device, and Start state. A saved tunnel configuration may still be stopped.

Dashboard success but API 404

Verify the Router origin and exact path prefix. A 404 can mean the wrong listener, an absent route, or a module that is not configured as expected. Inspect the response type to determine whether you reached a dashboard or an API. Do not solve this by copying a route from another product named Conduit.

401, 403, or unexpected redirects

A 401 commonly indicates missing or invalid authentication; a 403 commonly indicates insufficient permission. Actual behavior depends on the application's contract. Check identity scope, token expiry, header format, and route permissions without disabling authorization.

Inspect redirects before following them with sensitive headers. A redirect to an administration page or private origin can indicate the wrong endpoint or an application URL configuration issue. Exact Conduit configuration keys are release-specific and are not established here.

Webhook timeouts and duplicates

If no request appears in application diagnostics, verify the full callback URL, method, tunnel state, and device connection. If the request arrived, inspect signature validation and handler execution before changing networking. A slow handler can cause retries even when the tunnel delivered the request successfully.

Host sleep or tunnel disconnects

The public tunnel is available only while the selected client is connected and the tunnel is running. Host sleep, network loss, or client shutdown interrupts that availability. After restoring connectivity, verify the local request again, then start the saved tunnel and repeat the public request.

At the end of a test, stop the tunnel, remove obsolete provider callback URLs, and revoke temporary credentials. Stop Conduit separately through its verified deployment procedure. Closing public access does not prove the local backend has stopped.

Frequently asked questions