Build and verify your commerce application locally before opening remote access
Medusa provides an open-source commerce platform and framework for building customized commerce applications. This guide takes an installation-first approach: follow Medusa's current official setup documentation, start the application, identify its actual local HTTP endpoint, and verify that endpoint on the host machine. Once the local application works, we show how to expose it through a Localtonet HTTP tunnel without configuring inbound router port forwarding, firewall rules, a VPN, or a public IP address. Because Medusa installation requirements can change between releases, this article deliberately avoids guessing commands, ports, package-manager choices, or environment variables that are not established by the current official guide.
What you are self-hosting
Medusa is a commerce platform with a framework for extending and customizing commerce behavior. Its core commerce modules are open source, while separately identified Enterprise Edition materials may require a commercial agreement. Medusa can support direct-to-consumer stores, business-to-business systems, marketplaces, distributor platforms, point-of-sale projects, service businesses, and other applications that need reusable commerce primitives.
A standard Medusa project is not necessarily a single website. The official deployment overview distinguishes between the Medusa application, which includes the server and Admin dashboard, and one or more storefronts. The storefront connects to the Medusa server and is deployed separately. This distinction matters when planning remote access because the Medusa application and a separately running storefront can have different local endpoints.
In this tutorial, the immediate target is the working HTTP endpoint produced by the Medusa application setup. Do not assume that an endpoint copied from another tutorial matches your project. The hostname, port, path, and number of running services depend on the setup you complete and the current Medusa documentation.
Prepare for the current Medusa installation
Start with the current Medusa installation documentation rather than copying a command from an older article. Medusa evolves actively, and release changes can affect runtime versions, frontend tooling, package dependencies, and supported browsers. The official repository directs developers who want a local application to the Medusa Documentation learning guide.
Before running anything, read the prerequisites shown by the current installation page and compare them with the software installed on your host. Confirm the supported runtime version, package manager, database requirements, and operating-system expectations for the Medusa version you intend to use. Also read the release notes when upgrading an existing project. For example, Medusa v2.19.0 introduced breaking dependency and runtime requirements, which illustrates why a copied historical command is not a safe substitute for current documentation.
Decide whether you are creating a development environment or preparing a persistent self-hosted deployment. Local development may run multiple responsibilities in one process. The official production guidance recommends separating the Medusa server, which handles incoming requests, from the worker, which processes scheduled jobs, subscribers, and other background tasks. Production planning also includes PostgreSQL, Redis, persistent configuration, backups, monitoring, and sufficient resources.
The approved official project evidence directs local users to the current Medusa Documentation but does not establish one timeless command, package manager, port, container procedure, or set of environment variables. We therefore do not guess those details. Use the current official installation guide, record the endpoint displayed by your own setup, and continue below with that verified value.
Install and verify Medusa locally
Open the current Medusa installation guide
Begin with the Installation section of the official Medusa Documentation. Select the documented local installation path that matches your intended project and environment. If the guide presents multiple methods, follow one method completely rather than mixing commands or configuration from different approaches.
Satisfy the documented prerequisites
Install only the runtime, package manager, database, and supporting software required by the current guide. Check exact versions instead of assuming that any installed Node.js release or package-manager version is compatible. Keep database credentials out of shell history, screenshots, source control, and public documentation.
Create and configure the Medusa project
Follow the official prompts and configuration sequence to create the application. If you add a storefront, remember that it is a separate component with its own runtime and endpoint. Complete database initialization and any setup tasks required by the selected guide before attempting remote access.
Start the application locally
Use the startup procedure printed by the current Medusa guide or generated project. Watch the terminal output for errors involving dependencies, database connectivity, migrations, configuration, or occupied ports. Do not create a tunnel while the application is still failing to start.
Record the real local HTTP endpoint
Capture the exact hostname or local IP address, port, and relevant path reported by the running application. The available evidence does not establish a universal endpoint for every Medusa setup, so the value produced by your own installation is authoritative for this tutorial.
Verify the application from the host machine
Open the recorded endpoint in a browser or test it with an appropriate local HTTP client. Confirm that the expected Medusa interface or response loads and that authenticated areas behave correctly. Resolve application, database, CORS, and startup problems locally before adding Localtonet.
Understand the local and production architectures
A successful development server proves that the application can run, but it does not automatically create a production-ready commerce deployment. Development processes may combine responsibilities, include debugging behavior, or restart frequently. Production systems need persistent service management, restricted credentials, database backups, logging, updates, and a recovery plan.
| Component | Primary role | Remote-access consideration |
|---|---|---|
| Medusa server | Handles application API requests and serves the Medusa Admin as part of the application. | Use its verified local HTTP endpoint as a tunnel target only after applying appropriate authentication and access controls. |
| Medusa worker | Processes background tasks such as scheduled jobs and subscribers in a production architecture. | A worker is not normally exposed as a browser-facing HTTP service merely because the server is remotely accessible. |
| Storefront | Provides the customer-facing experience and connects to the Medusa server. | A separately running storefront may need its own tunnel and its configuration must reference a reachable server URL. |
| PostgreSQL | Stores Medusa application data. | Do not publish the database simply to make the web application reachable. The application should connect to it using restricted credentials. |
| Redis | Supports the deployed Medusa environment, including server session storage described by the deployment guide. | Keep it private unless a separately documented architecture explicitly requires controlled remote connectivity. |
The Localtonet HTTP tunnel in this guide should point to the confirmed Medusa HTTP service, not directly to PostgreSQL, Redis, or a background worker. Publishing supporting infrastructure unnecessarily increases risk. Use least-privilege database accounts, restrict network access, and protect all application credentials.
Connect the working Medusa endpoint through Localtonet
Once Medusa responds correctly on the host, Localtonet can provide remote HTTP access. Our client establishes an outbound connection from the device to a Localtonet relay server. This means the workflow does not require inbound router port forwarding, firewall changes, a VPN setup, or a public IP address.
An HTTP tunnel points to a local IP address and port on, or reachable from, the device running our client. Creating a tunnel does not start it automatically. The selected device must remain connected, the Medusa process must remain running, and the tunnel itself must be started. If any of those conditions stop, the public endpoint will no longer reach the application.
HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain process types, subject to current product availability and configuration. These process types serve the same local content at a public HTTPS address. Exact custom-domain DNS requirements should be checked against current documentation rather than inferred from another provider's setup.
Install and run our client
Install the Localtonet client on the Medusa host or on another device that can reach the verified Medusa endpoint. Keep Medusa running during tunnel configuration and testing.
Authenticate the correct device
Use the device-specific authentication token associated with the client that will run the tunnel. Never publish, guess, or embed that token in source code, screenshots, tutorials, or shared configuration.
Select an available relay server
Select the required Localtonet relay server or region from the current dashboard. Available server codes and regions can vary, so obtain the value from the product rather than copying a hardcoded value from an article.
Create the HTTP tunnel configuration
Choose an HTTP tunnel and enter the local IP address and port from the Medusa endpoint you already verified. Select the appropriate process type. Do not enter an example port unless it is the port actually used by your running application.
Start the tunnel
Use the Start button after reviewing the local target. Tunnel creation alone does not make the configuration active. The tunnel becomes usable only while the selected client is connected and the tunnel is running.
Test the assigned public address
Open the assigned public URL from a separate browser or network. Confirm that it reaches the intended Medusa service and not another process on the host. When access is no longer required, stop or delete the tunnel.
For the current dashboard workflow and supported options, consult our HTTP tunnel documentation .
Secure the remotely reachable application
A successful tunnel changes reachability, not application authorization. Treat the public URL as internet-accessible and review Medusa authentication, Admin accounts, permissions, CORS settings, secrets, and production configuration accordingly. Do not rely on an obscure URL as a security control.
Use strong credentials for Admin users, remove unused accounts, and apply least privilege to database and service credentials. Avoid placing secrets in frontend code or public repositories. Keep Medusa and its dependencies updated through the project's documented upgrade process, especially when release notes identify breaking changes or security-related updates.
Confirm which interface you intend to publish. A customer-facing storefront, an Admin dashboard, and an API have different audiences and risk profiles. If only a narrow integration endpoint is needed, avoid exposing a broader administrative interface unnecessarily. Stop the Localtonet tunnel when temporary testing or demonstration work is complete.
An HTTP tunnel makes a working local service reachable, but it does not replace Medusa's production deployment architecture, authentication, authorization, database protection, backups, monitoring, or operational controls. Review the current Medusa deployment guidance before using the application for real commerce traffic.
Troubleshooting the connection
Medusa does not work locally
Keep Localtonet out of the troubleshooting path until the local endpoint works. Review the Medusa process output for runtime compatibility, dependency, migration, database, and configuration errors. Verify that you are testing the exact address printed by the application.
The local endpoint works but the public URL does not
Confirm that the selected Localtonet device is connected, the tunnel is running, and the configured local IP address and port exactly match the verified Medusa endpoint. If our client runs on another machine, make sure that machine can reach the Medusa host over the local network.
The wrong service appears
Another application may be listening on the configured port, or the tunnel target may contain a copied example value. Stop the tunnel, identify the real Medusa listener, correct the target, restart the tunnel, and test again.
The application loads but browser requests fail
A public hostname can reveal application-level assumptions about origins, callbacks, cookies, API URLs, or CORS. Review the current Medusa documentation for the relevant configuration instead of guessing environment-variable names. If a storefront runs separately, confirm that it uses a server URL reachable from the remote browser.
Frequently asked questions
Can I install Medusa using a command copied from this article?
No installation command is printed because the supplied official evidence does not establish one permanent command or package-manager workflow. Follow the current Medusa installation documentation so that prerequisites, versions, prompts, and configuration match the release you are installing.
Which Medusa port should I enter in Localtonet?
Enter the port used by your verified local Medusa HTTP endpoint. Do not assume a universal default. Record the endpoint shown by your installation, test it locally, and use that actual local IP address and port as the HTTP tunnel target.
Do I need router port forwarding or a public IP address?
No. Our client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, firewall changes, VPN setup, or a public IP address.
Does creating a Localtonet tunnel start it automatically?
No. After creating the configuration, start it with the Start button. The public endpoint remains available only while the selected device is connected, the tunnel is running, and the Medusa application is reachable at the configured local target.
Should I expose PostgreSQL or Redis through the same HTTP tunnel?
No. The HTTP tunnel should point to the intended Medusa HTTP service. PostgreSQL and Redis are supporting services and should remain private unless a separately designed and secured architecture has a documented reason to make them remotely reachable.
Is a Localtonet HTTP tunnel a replacement for production deployment?
No. A tunnel provides reachability to the local application. Production Medusa deployment additionally requires appropriate server and worker architecture, PostgreSQL, Redis, authentication, backups, monitoring, resource planning, updates, and other operational controls described by Medusa's current deployment documentation.
Connect your verified Medusa application with Localtonet
Finish the official Medusa setup, confirm the real local HTTP endpoint, and then use our platform to make that endpoint remotely reachable without configuring inbound router port forwarding.
Get Started Free →
