Install Review Board and Access It Remotely with Localtonet

Understand the deployment before exposing it

Review Board is a web-based review platform for discussing proposed changes, commenting on diffs, tracking issues, and recording review decisions. A self-hosted deployment keeps its application, configuration, review data, and integrations under your administration. That control also makes your team responsible for updates, authentication, storage, recovery, and service availability.

There are two distinct layers to this setup. First, Review Board must serve a functioning website locally. Second, remote collaborators need a route to that website. With Localtonet, our client establishes an outbound connection to a relay server and provides a public URL for the local web endpoint. This does not require inbound router port forwarding, a public IP address, or VPN setup.

The tunnel does not install Review Board, provision its database, create a site, or configure repositories. It also does not make an unhealthy application healthy. A successful remote deployment begins with an exact local address and port that already work from the machine running the Localtonet client.

For the simplest network arrangement, run the Localtonet client on the Review Board host and use a loopback-bound web endpoint where the deployment supports it. If the client runs on another device, it must reach Review Board over an approved local network path. A loopback address always refers to the machine or network namespace using it, not automatically to a different host or container.

Choose Review Board 8 capabilities deliberately

The Review Board 8 release announcement introduces pinned Quick Access review actions, enhanced interdiff filtering, browser-dependent writing assistance, and expanded extension capabilities. It also describes integrations with Forgejo, GitLab CI, and RB Gateway 2.0. These release-specific statements should not be read as a guarantee that every integration or capability is included in every plan.

Office Document Review and User Roles are explicitly identified as Plus and Enterprise features in the Review Board 8 announcement. Ordinary user accounts, permissions, and authentication should not be confused with the paid User Roles feature. Likewise, permission to upload an attachment does not by itself establish access to document rendering and document-diff capabilities.

Choose the edition before acceptance testing. A team expecting to review Office documents should test that licensed workflow, while a Community deployment should focus on the code-review capabilities it actually provides. Localtonet changes reachability, not the Review Board license or edition.

Establish a supported Review Board installation

Use the installation section of the Review Board Administration Guide to select a release-specific path. A navigation entry for an operating system is not sufficient evidence that every release of that operating system is supported. Check the actual compatibility requirements for the Review Board version you intend to install.

For a new maintained deployment, evaluate the official Linux installer or Docker workflow first, according to your operations model. Keep manual Linux, macOS, Windows, and development installations as alternatives rather than mixing their instructions into the same procedure. A development release is appropriate only when testing unreleased behavior is intentional.

Decisions to make before running an installer

• Version and platform: record the exact Review Board release, operating-system release, architecture, and supported runtime or container prerequisites.
• Database: identify the supported engine and version, where it runs, how the application authenticates, and how backups will be restored.
• Web service: identify the supported server, application-serving mechanism, listener address, port, and service account.
• Storage: identify persistent database data, uploaded files, site configuration, and any repository-related files required by the deployment.
• Identity: choose the initial administrator and the intended authentication method for collaborators.
• Recovery: identify the service owner, backup destination, maintenance window, and acceptable recovery time.

Do not put administrator passwords, repository credentials, database passwords, API tokens, or Localtonet tokens in the deployment inventory. Record their approved secret-storage locations instead. Configuration and backups that contain secrets need restricted access even if the inventory itself contains no credentials.

Persistent storage for a container deployment

If you choose Docker, container replacement must not discard review data or uploaded files. Identify the documented mount locations before initializing the site, and distinguish database persistence from application-file persistence. Saving only the application container image is not a backup of a running review service.

The host-side published port is also separate from the container's internal listener. When the Localtonet client runs on the host, test the host-side endpoint. When it runs in a container, its loopback address points to that container. Do not copy a container IP into a long-lived tunnel configuration unless your network design intentionally provides a stable, reachable endpoint.

Site creation and initial administration

Review Board separates software installation from creating a Review Board site. Its rb-site tool participates in site management. The supplied extract does not establish the invocation, options, prompts, or generated web-service configuration for a current installation, so no universal command is asserted here.

The completed deployment should leave you with a known site location, a functioning database connection, a web server serving Review Board, and an administrator identity. Sign in locally before configuring repositories or remote access. Review authentication, access control, users, permission groups, repositories, e-mail, logging, and file storage in the administration interface.

Configure one test repository using an appropriately scoped service identity. Check that Review Board can retrieve the information needed for a review, not merely that the repository host accepts a login. Repository authentication and a reviewer's application permissions are different controls and both need testing.

Installation acceptance record

Before proceeding, write down the actual startup, stop, restart, log-inspection, backup, and restore procedures for the chosen path. Include the expected behavior after a host reboot. Do not assume that a container restart policy also starts the Localtonet client, or that an installer-managed application service automatically starts every supporting service.

This is an operational gate, not a substitute for installation instructions. If the deployment cannot yet produce a working local endpoint and a repeatable restart, finish that work before creating a public route.

Verify the local application before creating a tunnel

Test from the Review Board host first, then from the Localtonet client device if it is different. Use the exact local protocol, IP address, and port that will serve the application. There is no evidence-backed universal Review Board port in the supplied material.

The following diagnostic command is a general HTTP test, not a Review Board installation command. Run it in Bash on a machine with curl installed. Enter the endpoint produced by your deployment, without embedding credentials:

read -r -p "Working local Review Board URL: " RB_LOCAL_URL
curl --silent --show-error --output /dev/null \
  --write-out 'HTTP status: %{http_code}\n' "$RB_LOCAL_URL"

A response proves that something answered, not necessarily that Review Board is healthy. A redirect to sign-in can be expected; a redirect to an obsolete hostname is not a successful deployment check. Open the same endpoint in a browser and confirm that it serves Review Board rather than a default server page, directory listing, or another application.

Functional acceptance checklist

• Load the login page and confirm that styles, scripts, and images appear correctly.
• Sign in and sign out with a non-administrator test account.
• Open the administration interface with an authorized administrator account.
• Confirm that the non-administrator cannot perform administrative actions.
• Open a representative review request and its diff.
• Exercise the configured repository connection.
• Upload and retrieve a harmless test attachment if that workflow is required.
• Check application and web-service logs for request and startup errors.
• Restart the deployment through its supported procedure and repeat the core tests.

Use synthetic test content rather than proprietary code during early verification. A successful administrator login is not enough: administrators often have permissions that hide mistakes affecting ordinary reviewers.

Publish the verified endpoint with Localtonet

Use an HTTP tunnel for the normal Review Board browser interface. Our platform connects the selected client to a relay and forwards requests to the configured local service. Standard HTTP tunneling is not a VPN; VPN Manager is our separate private mesh VPN feature.

The following sequence follows the Localtonet lifecycle established in our product documentation. The HTTP tunnel documentation is the relevant dashboard reference. Current server choices, plan availability, and interface details must come from the live product rather than a hardcoded example.

Keep the initial exposure brief and avoid adding confidential review data until public-origin and access-control tests pass. A public URL is not a secret access credential. It may be shared, logged, or discovered independently of your intended audience.

Verify HTTPS, generated links, and proxy behavior

A working landing page does not establish that an application is correctly deployed behind a public HTTPS endpoint. Review Board must generate usable links, accept legitimate state-changing requests, and return redirects appropriate for the address collaborators use.

Use the public URL actually assigned to the tunnel for testing. Do not assume that setting a display name changes the application's canonical address, or that enabling public HTTPS changes how the local web server interprets incoming requests.

Redirects and sign-in

Open browser developer tools and inspect the Network panel while visiting the public address, signing in, and signing out. Redirect destinations should remain on the intended public origin, except for deliberate external authentication-provider transitions. A redirect to loopback or a private LAN address will not work for remote collaborators.

If requests alternate repeatedly between HTTP and HTTPS, stop and examine the application's understanding of its external scheme and the web server's redirect rules. Do not solve a loop by disabling request validation or blindly accepting client-provided forwarding headers.

Static assets and uploaded files

Check for failed script, stylesheet, image, and attachment requests. Browser mixed-content warnings can reveal assets generated with HTTP URLs while the page uses HTTPS. A 404 for an asset can instead indicate a local web-server mapping problem. Compare the failing public request with local behavior before changing tunnel settings.

API clients and generated URLs

Test the API operations your actual clients need, including authenticated operations where applicable. Inspect returned links for private hostnames or an obsolete public origin. An API authentication failure is not the same as a network failure: a reachable endpoint can correctly reject missing or insufficient credentials.

Generate a test notification and inspect its review link. Following that link from another network is a stronger check than merely seeing an e-mail arrive. Avoid pasting full API responses, cookies, or authorization headers into shared troubleshooting notes.

Callbacks and integrations

For an external sign-in provider or inbound integration, confirm the exact callback address required by that integration and register the active public address where appropriate. Do not invent a generic callback path. Test an entire round trip, not just the initial redirect.

Outbound webhooks from Review Board have a different network direction from inbound callbacks to Review Board. A tunnel can help a remote sender reach the application; it does not automatically repair Review Board's outbound connectivity to another service.

If the public hostname changes, revisit generated links, API-client configuration, registered callbacks, and bookmarks. For sustained collaboration, evaluate an available stable hostname option and verify its lifecycle in the current dashboard.

Protect review data before sharing access

Review Board can hold proprietary diffs, repository metadata, comments, attachments, integration configuration, and user information. Protect it as a development system, not merely a convenient demonstration website.

Use individual accounts and reserve administrator privileges for people who maintain the service. Give repository service identities and automation accounts only the access they require. Where anonymous access is not intended, test a signed-out browser directly against representative review and attachment URLs, not just the home page.

Test access boundaries with at least two ordinary accounts representing different permission groups. Confirm that a restricted user cannot access another project's data through a direct link or an API request. A hidden navigation item is not proof of authorization enforcement.

Keep repository credentials, administrator credentials, API tokens, and Localtonet device tokens out of screenshots and examples. Reviewers need the public Review Board URL and their own application credentials, not the token that identifies your tunneling device.

Publish the web endpoint only. Do not add public tunnels to the database, cache, container management interface, or other supporting services merely because they are part of the deployment. If the client-to-application connection crosses a network, evaluate that local connection separately from the public HTTPS connection.

Operate, recover, and troubleshoot the service

Restart and reboot acceptance

After a controlled restart, verify the database and web service first, then the local application, then the Localtonet client and tunnel. Finally test the public URL. This order makes a dependency failure easier to identify than restarting every component repeatedly.

Also test the expected behavior after a host reboot during an approved maintenance window. The existence of a saved tunnel configuration does not prove that its client is online or that the tunnel has started. Document the actual recovery sequence your deployment requires.

Backup scope and recovery testing

A useful backup covers the database, uploaded files, site configuration, and other deployment-specific state needed to recreate the service. Include an inventory of software versions, extensions, storage mappings, and service configuration. Protect backups with access controls appropriate to the source code and credentials they may contain.

Use a database-consistent backup procedure supported by the selected engine. A casual copy of live database files is not a universally safe backup. Coordinate database and file backups so restored records do not refer to missing attachments. The exact database commands and storage paths must be established by the installation path; the supplied evidence does not define them.

Restore into an isolated environment before relying on the backup. Prevent the restored instance from sending production notifications or callbacks. Verify user sign-in, a representative review, a diff, an attachment, and repository connectivity. Do not point the production tunnel at the recovery environment until it is deliberately promoted.

Upgrade procedure

1. Review compatibility and migration requirements for the target release, including extensions and repository integrations.
2. Schedule maintenance and stop public access while application state is changing.
3. Create and verify recoverable backups of persistent data and configuration.
4. Apply the software and site-upgrade actions documented for the chosen installation path.
5. Restart the required services and repeat local functional tests.
6. Start or recheck the tunnel, then repeat public-origin and integration tests.

This is an upgrade control checklist, not a release-specific command sequence. Do not assume replacing a container image completes a site migration. Likewise, rolling back only the application image may be unsafe after a database migration; recovery must account for compatible application code and persisted state together.

Diagnose failures by layer

For support, record the timestamp, affected URL path, HTTP status, relevant sanitized log message, and whether the same operation succeeds locally. Avoid collecting secrets unnecessarily. Full request headers may include cookies or bearer tokens, and response bodies may contain source code.

Frequently asked questions