How to share one private staging service with a teammate

A staging app in an office or on a developer machine should be easy for the right teammate to reach. The common shortcuts are less appealing: publish it on the internet and rely on a password, or give the teammate a broad network route when they only need one service.

I’m building Airmsh, and I’m looking for developers willing to test a narrower workflow. Here’s the approach we use, plus what I’d check with any private-access tool.

Start with the service boundary

Write down the exact service you want to share: which host runs it, which address and port it listens on, and who should be allowed in. For example, a staging API on a development machine may need to be reachable by one teammate’s laptop—not by every device on their network.

Reachability and authorization are separate questions. An encrypted connection gets traffic to the host; an access rule decides whether this user or device may use the particular service. Your application’s own authentication still matters.

A concrete Airmsh setup

1. Install Airmsh on the host and on the teammate’s device. Sign in on both, turn on the private network, and confirm the devices appear in Devices.
2. Start the staging website or API on the host. In Endpoints → Administration, create an Endpoint for that host, service address, port, and protocol.
3. Grant access to the intended user, group, or device. From the teammate’s device, connect to the Endpoint and open its private address.
4. Test the negative path too: try an account or device that was not granted access. Then revoke the grant and check that the previously allowed client can no longer reach the service.

That last step matters. A setup is not finished just because the happy path works.

Limits worth knowing before you try it

The host, client, and staging service need to be online. Airmsh does not automatically issue a trusted HTTPS certificate for your backend; configure one if the app requires HTTPS. Apps that force their own DNS-over-HTTPS resolver may not use the private resolver. Mobile store releases can also lag the current website download, so check which build you are testing.

If your goal is an open link for arbitrary visitors, a private Endpoint is probably the wrong fit: recipients need the client and an access grant. Use an appropriately authenticated public-facing setup for that case.

The getting-started guide has the current steps, and downloads are here.

If you already share a staging site, internal dashboard, or API with teammates, I’d value a real beta test. Use a test service rather than production secrets, then tell me your OS, what you tried, and where setup, connection, permissions, or revocation was confusing. What would make you comfortable using this in your own workflow?