How can we help?

How a request reaches the app on your computer, which name, address and key does which job, and who can do what.

Sign in, then create a Groundhog workspace or join one from an invitation before you create a tunnel.

Choose a tunnel name, save the connection key that is shown only once, and fill in your app’s port.

Run the Aspire sample, enter your connection key, and check that the public address reaches your computer.

Install the Aspire package, give one of your resources a public address, and pass that address to the apps that need it.

Expose a YARP or other gateway that proxies to internal services, and give those services the public address for webhook callbacks.

Read the tunnel name and key from each developer’s user secrets, so a team shares one AppHost and each person runs their own tunnel.

Install the Groundhog CLI on Windows, macOS or Linux, keep it up to date, and remove it when you no longer need it.

Give an app on your computer a public address with the Groundhog command-line tool, without Aspire.

Read a tunnel’s state, stop it safely, rotate or revoke its keys without downtime, rename it, delete it, and keep its client up to date.

Follow live requests, find failing ones, capture text bodies on purpose, and read retention and offline gaps correctly.

Let anyone, workspace members, API keys or IP ranges reach each path of a tunnel, from the dashboard, the CLI or Aspire.

Make host checks, webhooks, sign-in callbacks, local HTTPS and live reload work through your tunnel.

Invite people, choose their roles, withdraw access, leave or delete a workspace, and delete your account.

Fix an old sample, a NuGet restore error, a rejected key, or a public address that does not reach your app.

The difference between a public tunnel address and the service address, and how to check the Groundhog service is reachable.