Install the Reloop stack, verify the correct web listener, and publish only the HTTP interface you intend to expose
Reloop is an open-source email infrastructure platform with transactional email, SMTP relay, campaigns, inbound mail, templates, analytics, webhooks, contacts, and workflows. This guide covers its documented production installer and Bun-based development workflow on Ubuntu or Debian, then explains where a Localtonet HTTP tunnel fits. Because Reloop contains web, API, mail, database, and supporting services, identifying the correct HTTP boundary matters as much as starting the stack. We will also distinguish Reloop's domain-based production topology from development or private deployments where a Localtonet public HTTPS address can provide complementary remote access.
📋 What's in this guide
What you are self-hosting
Reloop describes itself as open-source email infrastructure for sending, receiving, and managing email. Its repository documents transactional email through a REST API and SMTP relay, email campaigns, inbound email processing, a visual template editor, delivery analytics, delivery-event webhooks, contacts and lists, automated workflows, and granular API-key management with team-level permissions.
This is not a single-process web application. The repository is a monorepo with backend services, frontend applications, local Docker services, PostgreSQL-backed data, and multiple local ports or gateway routes. A browser dashboard, REST API, SMTP relay, database, and queue or other supporting service may all listen separately. A successful TCP connection therefore does not prove that you found the interface that should be published.
Reloop webhooks describe application events such as email delivery changes. Localtonet platform-wide Token/Tunnel webhooks report when a selected token or tunnel becomes Connected or Disconnected. One system does not replace or configure the other.
Reloop's repository says the software can be self-hosted with Docker, Kubernetes, or bare metal. The documented one-command path covered here is specifically for a fresh Ubuntu or Debian server. The development workflow uses Bun and the repository's setup automation. This article does not present a custom Kubernetes or hand-built bare-metal deployment because the supplied project evidence does not provide those procedures.
Choose the right installation path
Choose the deployment model before modifying the machine. The production installer and the source-development workflow have different network boundaries and operational expectations.
| Path | Documented environment | Best fit | Primary startup method |
|---|---|---|---|
| Production VPS installer | Fresh Ubuntu 22.04 or 24.04, or Debian 12 or 13 server | A complete domain-based server deployment | Official privileged installation script |
| Bun development workflow | Source checkout with Git, Bun, Docker services, environment configuration, and database setup | Development, evaluation, contribution, and local code changes | bun setup, followed by bun dev |
| Existing Reloop deployment | An installation that is already healthy and locally reachable | Adding temporary or complementary remote access | The deployment's existing service-control procedure |
Use the production installer when you want Reloop to run its documented preflight checks, install Docker, prompt for a domain, generate production secrets, deploy every service, verify health, and print the DNS records required by the deployment. The instruction to use a fresh server is important. An existing reverse proxy, database, SMTP daemon, Docker stack, or control panel may conflict with the installer.
Use the development workflow when you need the repository and its per-service development environment. Development mode may include multiple listeners, verbose logs, live-reload processes, and supporting containers. It should not be treated as a hardened production deployment merely because it works from another device.
The current repository describes Reloop as licensed under Apache License 2.0 with additional Reloop Labs use restrictions. Read the repository's current LICENSE file for the exact terms before redistributing modified software or offering Reloop as a hosted service. The short repository description is not a substitute for the license text.
Prepare Ubuntu or Debian
Production server requirements
The production installer targets a fresh server running Ubuntu 22.04, Ubuntu 24.04, Debian 12, or Debian 13. The supplied project evidence does not establish support for earlier releases or other Linux distributions through this installer.
Before proceeding, make sure you have:
- Administrative access through
sudo. - Outbound internet connectivity for downloading the installer, packages, and container images.
- Control of the domain that you will provide to the installer.
- Access to that domain's authoritative DNS provider.
- A fresh host without unreviewed conflicts from an existing web, mail, database, or Docker stack.
- A secure place to retain generated credentials and deployment information.
Confirm the installed operating system before running a privileged installer:
cat /etc/os-release
Compare the displayed ID and VERSION_ID with the supported production list. This command only reads operating-system metadata.
Development requirements
The repository's quick start requires Git and Bun. Its setup documentation is also described as covering environment configuration, Docker services, database setup, local ports, gateway routes, backend services, frontend applications, and per-service commands. PostgreSQL is the documented store for delivery analytics and related data.
Check whether the required tools are available before cloning:
git --version
bun --version
docker --versionIf Docker is installed, verify that the current account can reach the daemon:
docker infoA permission error is different from a stopped Docker daemon. Resolve the condition according to your host's Docker installation policy. Do not routinely run the complete development stack as root merely to conceal a permissions problem.
The supplied project extract does not state fixed Bun, Docker, PostgreSQL, CPU, memory, or storage minimums. Use requirements from the exact Reloop revision you check out. Do not select arbitrary versions from an older tutorial if the current setup task reports a different requirement.
Plan the network boundary before installation
Decide whether you need browser access to the dashboard, programmatic access to the REST API, or both. Do not begin by exposing every port. The Localtonet client must run on the same device as the chosen loopback-only service or on another device that can route to the selected private address.
Also distinguish application DNS from tunnel addressing. Reloop's production installer asks for a domain and prints deployment-specific DNS records. A Localtonet Random Sub Domain or Custom Sub Domain is not a replacement for those mail and application records.
Install Reloop with the production VPS installer
The current repository documents the following one-command installation for a fresh supported server:
curl -fsSL https://reloop.sh/install.sh | sudo bashConfirm that the URL is the official Reloop installer before running it. If your infrastructure policy requires review, download and inspect the script through your approved process instead of piping it directly to a privileged shell.
Confirm the supported fresh-server environment
Use Ubuntu 22.04, Ubuntu 24.04, Debian 12, or Debian 13. Confirm sudo access, outbound connectivity, domain control, and DNS access.
Run the official installer
Execute the documented command from a shell on the server. Monitor its complete output instead of disconnecting immediately after it starts.
Allow the preflight checks and Docker installation to complete
The installer checks the host and installs Docker as part of the documented workflow. If a preflight check fails, correct the reported condition before retrying.
Enter the deployment domain
Provide the exact domain controlled for this installation. The available evidence does not document a production mode that omits this domain prompt.
Let the installer generate secrets and deploy every service
Do not interrupt secret generation or service deployment. Do not copy generated credentials into tickets, public screenshots, repositories, or tunnel configuration.
Review the health-verification result
The installer verifies service health after deployment. Treat a failed health check as an incomplete installation, even if one web page or container responds.
Publish the exact DNS records printed by the installer
Add the generated records through the authoritative DNS provider. Do not substitute examples from another installation because names and verification values can be deployment-specific.
First access and administrator initialization
The available repository summary confirms that the installer prompts for a domain, deploys every service, verifies health, and prints DNS records. It does not provide the first-login path, an administrator bootstrap command, or an administrator-creation sequence. Do not invent a default account, password, registration URL, or container command.
Use the completion information printed by the installed revision to identify its supported first-access URL and initialization procedure. If no access instruction is printed, consult the deployment documentation that matches that revision before publishing the interface. Never enable unrestricted registration or alter database records merely to create an account unless Reloop explicitly documents that operation.
Inspect the deployed services without guessing their names
Docker can show the containers and published ports created by the installer:
sudo docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'This is an inventory command, not a substitute for Reloop's architecture and port reference. Container names, image names, internal ports, and published ports can change between revisions. Use the installer's health output and the documentation for the installed version to decide which component is intended for browser or API access.
Set up Reloop for development with Bun
Reloop's published quick start consists of cloning the repository, entering its directory, running the setup task, and starting development mode:
Clone the repository
Retrieve the current Reloop source with Git.
git clone https://github.com/reloop-labs/reloop.gitEnter the repository directory
Run workspace commands from the cloned project root.
cd reloopRun the setup workflow
Start the repository's setup task and read every prompt or error relating to environment configuration, Docker services, and database preparation.
bun setupStart development mode
Start the monorepo development workflow and keep the terminal available so that service URLs and errors remain visible.
bun devEnvironment configuration
The repository explicitly points developers to its Setup Guide for environment configuration, but the supplied current evidence does not include the variable names, example file path, required values, or secret-generation commands. Those values are version-sensitive and should not be guessed. In particular, do not create plausible-looking database URLs, signing keys, callback URLs, or public-base-URL variables without matching them to the checked-out revision.
After bun setup, inspect its output for any generated or requested environment files. Keep secret-bearing files out of commits and public support logs. If setup stops because a required variable is absent, use the name and format required by the repository revision rather than adapting an unrelated application's configuration.
Docker and database behavior
Reloop's setup material is described as covering Docker services and database setup, and the project identifies PostgreSQL as the store for delivery analytics. The quick-start evidence does not enumerate the development container set, Compose project name, database credentials, schema commands, or migration commands. Consequently, generic commands such as creating an arbitrary PostgreSQL database or running a guessed migration script would be unsafe.
You can inspect Docker after setup without assuming names:
docker ps
docker ps -aA running container is not sufficient proof that the schema is current or that every application service is healthy. The authoritative indicators are successful setup output, successful development startup, documented health checks, and working application requests.
All-services and per-service startup
bun dev is the verified top-level development command. The repository also states that per-service setup guides and commands exist, but the supplied extract does not list those commands. Do not infer commands from package names or run every workspace independently unless the current repository documentation instructs you to do so.
This distinction matters when creating a tunnel. A frontend development server might depend on an API gateway, authentication service, or callback URL that is only valid through the documented gateway route. Tunneling an internal package listener can produce a page that partially loads while authentication, API calls, or redirects fail.
Stopping bun dev can stop the services it controls. Supporting Docker containers may have a separate lifecycle. Localtonet provides reachability to a running target, but it does not supervise or restart Reloop processes.
Identify and verify the HTTP endpoint locally
Local verification should answer five questions:
- Which component owns the listener?
- Is it the dashboard, documented gateway, or REST API?
- Which address and port does it use?
- Does it expect a particular host name or public URL?
- Can the Localtonet client device reach it?
Start with Reloop's output and port reference
For development, read the output from bun dev and the current Reloop port reference. For production, begin with installer output, health results, and the deployed revision's VPS documentation. Prefer a documented gateway or browser-facing listener over an internal monorepo service.
The repository confirms that a port reference exists for local ports and gateway routes, but the supplied evidence does not contain its numeric values. This article therefore does not hardcode an unverified dashboard port. A stale port can expose the wrong service or fail after an architecture change.
Inspect active listeners
sudo ss -ltnpCorrelate the result with Reloop's process output or Docker port mappings. Do not select a port solely because it is open.
| Observed binding | Meaning | Implication for Localtonet |
|---|---|---|
127.0.0.1:PORT |
IPv4 loopback only | Run our client on the same host and use 127.0.0.1 as the target address |
0.0.0.0:PORT |
All available IPv4 interfaces | The same host can use loopback; another device may use a reachable private address if policy permits |
PRIVATE_IP:PORT |
One selected network interface | The Localtonet client must be able to route to that exact private address |
Send a local HTTP request
Replace the placeholder with the documented numeric port:
curl -I http://127.0.0.1:RELOOP_HTTP_PORT/Use a different host if the service is not bound to loopback. An HTTP response confirms that an HTTP server is reachable, but it does not by itself prove that the server is the supported public gateway. A redirect may also reveal that the application expects its configured production domain.
Open the same address in a browser when testing the dashboard. For API verification, use a documented, non-destructive route and Reloop's required authentication. Do not invent a health path or expose an API key in shell history solely to test network access.
Do not expose PostgreSQL, a queue, SMTP, a Docker management endpoint, an internal development service, or a debugging interface through an HTTP tunnel. Confirm the protocol and application identity first.
Understand the production domain and Localtonet topology
Reloop's production installer requires a domain and prints DNS records. That workflow is materially different from a local development server that has no public address. It indicates that the production deployment is designed around domain-based access and email DNS configuration.
The supplied project evidence does not establish whether every printed DNS record is for the web interface, email authentication, inbound mail, or another service. It also does not state which internal production listener is supported as an alternate tunnel target. Therefore, do not assume that tunneling a container's published port is an approved replacement for the domain configured during installation.
| Deployment situation | Role of Localtonet | Recommended decision |
|---|---|---|
| The Reloop production domain already provides the required web access | Potentially redundant for the same interface | Keep the documented Reloop topology unless a separate access requirement exists |
| The dashboard or API is intentionally private but locally reachable | Can provide complementary public HTTPS access | Use only a documented browser-facing or gateway listener |
| A development deployment runs on loopback | Can provide temporary remote access for testing | Run our client on the same host and keep application authentication enabled |
| The goal is SMTP or inbound-mail delivery | An HTTP tunnel is not the appropriate mechanism | Follow Reloop's mail listener, domain, authentication, and DNS procedures |
Host headers, redirects, origins, callbacks, and public base URLs
Domain-aware applications can validate the HTTP Host header, redirect to a canonical domain, restrict trusted origins, or construct authentication callbacks from a configured public base URL. If Reloop is configured for one production domain and receives requests through a different Localtonet address, those behaviors may affect login, cookies, redirects, API calls, or browser-origin checks.
The supplied Reloop evidence does not name configuration variables for trusted hosts, allowed origins, callback URLs, or public base URLs. It also does not authorize overriding the production host header. Do not invent environment-variable names or disable origin checks. If a Localtonet URL redirects to the installer domain or authentication fails only through the tunnel, compare the behavior with the current Reloop configuration documentation for the installed revision.
A page rendering successfully does not prove that sessions, authentication callbacks, API requests, webhook URLs, and redirects use the correct public origin. Use the Reloop domain topology as installed unless its current documentation supports an alternate external address.
Expose a verified Reloop HTTP service with Localtonet
With Localtonet, our client establishes an outbound connection to a relay server. The resulting HTTP tunnel provides a public HTTPS address without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. It remains available only while the selected client is connected and the tunnel is running.
Before configuring the tunnel, use the current Localtonet documentation to obtain the supported client installation path for your operating system. Installation commands and packages can change, so this guide does not invent a Linux command that is not present in the supplied current product evidence.
Install and run the Localtonet client
Install the current supported client on the Reloop host or another device that can reach the verified HTTP service. A loopback-only target requires the client on the same host.
Create or open the HTTP tunnel configuration
Use the HTTP tunnel page rather than a raw TCP, UDP, File Server, proxy, or VPN configuration.
Select the process type
Choose Random Sub Domain, Custom Sub Domain, or Custom Domain according to the options currently available to your account and the public-address design you have verified with Reloop.
Select the device AuthToken
Choose the token for the connected client device that can reach Reloop. Device tokens are secrets and must not appear in screenshots, repositories, support posts, or application configuration.
Select an available server
Choose a current relay server or region from the dashboard. Do not copy a server code from an older article because available values can vary.
Enter the verified local IP address and port
Use the exact Reloop HTTP target tested locally. Use 127.0.0.1 only when the Localtonet client and Reloop listener are on the same device.
Start and test the tunnel
Creating the configuration does not start it. Select Start, wait for the client and tunnel to become connected, and test the assigned public HTTPS address from another browser or network.
The current Localtonet HTTP tunnel documentation should be used to confirm the live interface and field names. If you use Custom Domain, follow the current Localtonet DNS instructions rather than copying unrelated DNS records. Localtonet custom-domain records and Reloop's email-domain records have different purposes.
Public-address options
| Process type | Public behavior | Reloop consideration |
|---|---|---|
| Random Sub Domain | Provides an assigned public HTTPS address | Useful for temporary access only if Reloop accepts the resulting public origin |
| Custom Sub Domain | Uses a selected subdomain where supported | A stable address can help, but it still must match Reloop's origin and callback expectations |
| Custom Domain | Publishes the same local content through a configured domain | Requires current Localtonet DNS guidance and must not conflict with Reloop's existing domain design |
Secure the public HTTP boundary
A public address changes the service's exposure. TLS at the public tunnel edge protects the browser-facing HTTPS connection, but it does not replace Reloop login controls, permissions, API-key authentication, secure cookies, host maintenance, or correct application configuration.
Expose the smallest useful surface
Target only the documented dashboard, gateway, or API listener required by the workflow. Do not expose PostgreSQL, queues, Docker sockets, internal development servers, SMTP, or every port displayed by ss or Docker.
Keep application authentication enabled
Preserve Reloop authentication and team permissions. Continue using Reloop API keys for documented API requests. A random public URL is not an authorization control, and a tunnel does not create or validate Reloop identities.
Use least-privilege credentials
Reloop documents granular API-key management with team-level permissions. Use credentials limited to the required function. Do not embed API keys in a public URL, browser bookmark, frontend source, Localtonet target, or tutorial command.
Separate Reloop and Localtonet secrets
A Localtonet device token identifies the client device that runs a tunnel. A Reloop API key authorizes application activity. Database credentials, SMTP credentials, signing secrets, and administrator sessions are separate again. Do not reuse or casually store these secrets together.
Stop temporary access when it is no longer needed
Stop or delete the tunnel after a maintenance or development session. For continuous access, supervise both the Reloop deployment and Localtonet client, keep the host patched, and monitor tunnel connectivity. A tunnel becomes unavailable when its selected client disconnects.
Reloop's SMTP relay and inbound-mail functions involve separate protocols, credentials, domain authentication, routing, and DNS. Although Localtonet supports raw TCP tunnels, safely publishing an email service requires a separate design and is outside this HTTP-focused tutorial.
Operate, update, back up, and troubleshoot the deployment
Development startup and shutdown
Start the verified development workflow from the repository root:
bun devUse the terminal's normal interrupt mechanism to stop the foreground development process. Supporting Docker services may continue after that process exits. The supplied project extract does not provide the current Compose project name or an official all-services shutdown command, so do not run a guessed command that could stop unrelated containers.
Before deleting development resources, inspect what exists with docker ps -a and identify the project-owned containers and volumes through the current Setup Guide. Database volumes may contain persistent Reloop data.
Production service control and logs
The installer deploys every service and verifies health, but the supplied evidence does not identify a stable installation directory, Compose file path, systemd unit, container naming convention, or wrapper command. Use the service-control procedure printed or installed by the exact Reloop release.
For initial diagnosis, inventory running containers:
sudo docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'After identifying a Reloop-owned container, Docker can display its logs without assuming a project-specific command:
sudo docker logs CONTAINER_NAME
Replace CONTAINER_NAME only after confirming ownership. Do not post logs publicly until credentials, tokens, email addresses, domains, message contents, and personal data have been removed.
Persistent data and backups
PostgreSQL contains application data, while configuration, generated secrets, and other state may be stored in deployment-specific files or Docker volumes. The supplied evidence does not specify their exact production paths or a verified Reloop backup command. A filesystem copy of a live database volume is not automatically a consistent database backup.
Before changing or updating the deployment, identify all persistent resources through the installed revision's VPS documentation and Docker configuration. Back up the PostgreSQL data using Reloop's documented database-consistent method, preserve required configuration and secrets securely, and verify that the backup can be restored. Do not claim recovery readiness until a restore has been tested on an isolated system.
Updates, rollback, and recovery
The repository publishes releases and a changelog. The supplied release evidence identifies v0.9.0 as the displayed latest release, but a production update should follow the instructions for the version installed at the time of maintenance. Do not assume that rerunning the installation script is an upgrade procedure.
A safe update plan should establish all of the following before changes begin:
- The currently installed Reloop revision.
- The target revision and its migration requirements.
- A verified backup of persistent data and required configuration.
- The documented update command for that deployment method.
- The documented rollback limitations, especially after database migrations.
- A maintenance window and local health-verification procedure.
If Reloop does not document downgrade support for a migration, do not assume that restoring older application containers against a newer database is safe. Recovery may require restoring both the earlier application revision and its matching database backup.
The installer fails during preflight checks
Read the first failure rather than rerunning the script repeatedly. Confirm the operating-system release, sudo access, outbound connectivity, DNS control, and whether existing web, mail, database, or Docker workloads conflict with the fresh-server requirement.
bun setup fails
Confirm that Git, Bun, and Docker are available in the same shell. Read the setup output for the exact missing runtime, environment variable, container, or database operation. If setup created partial resources, identify them before deleting anything, especially environment files, databases, and volumes.
bun dev runs, but the browser cannot connect
Keep the development terminal open and inspect service-level errors. Compare the printed URL with sudo ss -ltnp and Docker mappings. Test on the same host first. A service bound to 127.0.0.1 will not accept direct connections to the server's private LAN address.
The local endpoint works, but the public URL fails
Confirm that the correct Localtonet device is connected, the selected token belongs to that device, the tunnel has been started, and the local IP address and port exactly match the successful local test. If our client runs on another machine or inside a container, 127.0.0.1 refers to that environment, not automatically to the Reloop host.
The public URL redirects elsewhere or authentication fails
Compare the redirect location and browser errors with Reloop's configured production domain. Investigate documented trusted-host, origin, callback, cookie, and public-URL requirements for the installed revision. Do not disable validation or invent environment variables to force the alternate address.
The public URL opens the wrong service
Stop the tunnel immediately. Recheck the listener against Reloop's current port reference, gateway routes, process output, and Docker mappings. Correct the target only after the intended dashboard or API responds locally.
The dashboard works, but API calls fail
A rendered page proves that one route is reachable. It does not prove that the API gateway, browser origin, authentication header, base URL, or callback configuration is correct. Use Reloop's documented API route and credentials, then inspect browser and service logs for application-level errors.
Email sending or inbound delivery fails
Do not change the HTTP tunnel while diagnosing mail delivery. Confirm the DNS records printed by the installer, domain status, SMTP credentials, sending configuration, and inbound routing through Reloop's mail documentation. Dashboard reachability and mail deliverability are separate layers.
The tunnel disconnects
A Localtonet tunnel is available only while the selected client is connected and the tunnel is running. Check whether the client stopped, the machine shut down or slept, connectivity failed, or the tunnel was manually stopped. Localtonet Token/Tunnel webhooks can report Connected and Disconnected status changes for a selected Token Group.
Check Reloop service health, then the local HTTP request, then reachability from the Localtonet client device, then client connectivity, then tunnel status, and finally the public HTTPS address. This order isolates the failing layer without changing several configurations at once.
Frequently asked questions
Which Ubuntu and Debian releases does the production installer support?
The documented installer targets a fresh Ubuntu 22.04, Ubuntu 24.04, Debian 12, or Debian 13 server. The supplied evidence does not establish support for other releases through that one-command workflow.
What port should I enter in the Localtonet HTTP tunnel?
Use the documented browser-facing or gateway port for the exact Reloop revision you installed. Confirm it with Reloop's output, port reference, Docker mappings, and a successful local HTTP request. Do not select a database, SMTP, queue, or internal development listener.
Is Localtonet necessary for a production Reloop installation?
Not necessarily. The production installer asks for a domain and prints DNS records, so the deployment is designed around a domain-based topology. If that topology already provides the required web access, another public URL may be redundant. Localtonet is most useful for a private listener, temporary maintenance access, development access, or another explicitly supported HTTP boundary.
Does Localtonet configure Reloop's DNS records?
No. Apply the deployment-specific DNS records printed by the Reloop installer through your DNS provider. A Localtonet HTTP tunnel only publishes the selected HTTP target. It does not configure sending-domain authentication, inbound mail routing, or other Reloop DNS requirements.
Can I expose Reloop SMTP through this HTTP tunnel?
No. An HTTP tunnel must target an HTTP application such as the verified dashboard, gateway, or REST API. SMTP is a different protocol and requires a separate security, authentication, DNS, routing, and deliverability design.
Should I use the VPS installer or the Bun workflow?
Use the VPS installer for the documented complete deployment on a fresh supported server. Use the Bun workflow for development, evaluation, contribution, and source changes. Development mode should not be treated as a hardened production environment.
Can the Localtonet client run on another device?
Yes, if that device can route to the verified Reloop HTTP address and port. If Reloop listens only on 127.0.0.1, run our client on the same host unless Reloop documents a secure alternative binding.
Does creating a Localtonet tunnel start it automatically?
No. After creating the configuration, select Start. The public endpoint remains available only while the selected client device is connected and the tunnel is running.
Does the public HTTPS address remove the need for Reloop authentication?
No. Keep login controls, team permissions, API-key authentication, and least-privilege access enabled. Localtonet provides network reachability and a public HTTPS address, while Reloop remains responsible for application identity and authorization.
Connect a verified Reloop HTTP endpoint with Localtonet
Install and validate Reloop first, identify its supported browser-facing or gateway listener, and check any domain, redirect, origin, and callback requirements. Then create an HTTP tunnel to that exact local target while keeping Reloop authentication enabled.
Get Started Free →
