Configurable Ports for Dashboard and Mailhog

[jovermier]

Description

feat: configurable ports for Dashboard and Mailhog services

Problem

The Nhost CLI supports custom ports for most services such as Hasura, Auth, and Postgres, but the ports for the Dashboard and Mailhog services are currently hardcoded. This limits the ability of developers to avoid port conflicts or customize their local environment, particularly when running multiple Nhost instances simultaneously.

Solution

This PR adds two new CLI flags and associated support throughout the codebase to allow customization of Dashboard and Mailhog ports:

• --dashboard-port with env fallback NHOST_DASHBOARD_PORT
• --mailhog-port with env fallback NHOST_MAILHOG_PORT

Key implementation updates:

• Introduced new UintFlag definitions for both ports in cmd/dev/up.go.
• Extended the ExposePorts struct to include Dashboard and Mailhog fields.
• Updated service creation functions (dashboard, mailhog) to accept the new ports and apply them using the ports() utility.
• Adjusted getServices() to pass the port values correctly to each respective service.
• Ensured printInfo() remains consistent and informative with the correct URLs displayed (though it still prints the base HTTP port for Dashboard and Mailhog to preserve the current behavior; further enhancements to output format could be addressed in a future PR).

Notes

• Default behavior remains unchanged if the new flags are not specified.
• This brings Dashboard and Mailhog in line with other services for port configurability.
• Enables better local dev experience with multiple environments or custom tooling.

Example Usage:

nhost up  \
--dashboard-port 3001  \
--mailhog-port 8026

[dbarrosop]

Hi, this is already possible via the http flag.

[jovermier]

I tried the following and didn't see a way to get to the dashboard and mailhog.

nhost up \
  --disable-tls \
  --hasura-port 8080 \
  --hasura-console-port 8081 \
  --auth-port 8082 \
  --storage-port 8083 \
  --functions-port 8084 \
  --postgres-port 8085

[jovermier]

Also adding --http-port 8086 doesn't seem to expose the dashboard and mailhog on ports that I can proxy.

[jovermier]

I updated my original post description to better describe the changes of the code.

[dbarrosop]

sorry, I am still unsure what problem this is solving.

but the ports for the Dashboard and Mailhog services are currently hardcoded

This is not accurate, you can use --http-port to select the port where all services will be exposed (i.e. with --http-port 8443 https://local.dashboard.local.nhost.run:8443, https://local.auth.local.nhost.run:8443, etc)

This limits the ability of developers to avoid port conflicts or customize their local environment, particularly when running multiple Nhost instances simultaneously

The flag --hasura-port was needed time ago before we had our dynamic resolver so users could connect from their android/iphone devices when doing mobile development but those are no longer needed as you can basically set --local-subdomain 192-168-1-1 and that will generate urls like https://192-168-1-1.dashboard.local.nhost.run which can then be accessed in the network via the IP 192.168.1.1 which I think is actually what you want/need if you are talking about setting up a proxy. If you are doing what I think you are doing what you want to do is the following:

1. Start nhost with the public IP of your proxy, i.e., nhost up --local-subdomain 1-1-1-1, which will get you urls resolving the IP 1.1.1.1 (don't use 1-1-1-1 as that's cloudflare's DNS but you probably know that :P)
2. Configure your proxy to connect to the IP of the host running nhost (make sure docker is configured to listen to that IP)
3. Use the subdomain 1-1-1-1, region local in the SDK and access the dasbhoard/mailhog/hasura using the various urls as https://1-1-1-1.$service.local.nhost.run (the CLI should've printed the correct urls)

Notes: You will need to just passthrough TLS as that's handled by the nhost cli and you may need to protect in your proxy the dashboard and mailhog as those have public access without authentication.

[jovermier]

I'm running Nhost inside a Coder workspace (VS Code in the browser). Most services are accessible remotely via Coder’s port-based subdomain routing, but a few issues remain:

• Dashboard and Posthog aren't remotely accessible
• Can't connect local apps (e.g. React) to Nhost Docker endpoints
• Overriding ports (e.g. using 8086 for Hasura) may be causing conflicts with how Nhost in React needs to be configured

Coder maps each port to a unique subdomain in the format:

https://<port>--<branch>--<project>--<username>.coder.example.com

[dbarrosop]

The thing is you shouldn't need to do that. What you should do is the following:

• Starts the CLI with the --local-subdomain 1-2-3-4 flag where 1-2-3-4 is the IP of the proxy
• The proxy only proxies port 443 (or a different one if you chose another one). No processing of the Host header or anything.
• Then in the SDK you configure the subdomain 1-2-3-4 and the region local

And that's it, going to https://1-2-3-4.{auth,dashboard,storage,mailhog,etc}.local.nhost.run should send you to 1.2.3.4:443 which should forward the request to traefik which will then point you to the right place. This has the advantage that it all works as if it was a normal setup using the cloud or the local CLI, no need for the SDK to be configured in any special way.

The only issue I foresee here is that you currently would need one IP per project but if this setup works for you it should be fairly easy to extend our "Magic DNS" to ignore prefixes so you can do 1-2-3-4-some-project.auth.local.nhost.run, 1-2-3-4-other-project.auth.local.nhost.run so you can configure 1-2-3-4-some-project in the SDK.
I implemented this so now any prefix to the host is ignored:

❯ host 1-1-1-1-asd.auth.local.nhost.run
1-1-1-1-asd.auth.local.nhost.run has address 1.1.1.1

❯ host 1-1-1-1-wqe.auth.local.nhost.run
1-1-1-1-wqe.auth.local.nhost.run has address 1.1.1.1

Let me know if it works and if it doesn't why so we can look into this. If we can't make it work we can merge the PR but I would like to figure this out first because we keep adding more and more flags for edge cases and that only makes the cli more difficult to use. If you are in a hurry we can build a temporary cli with your patch so you can use it in the meantime.

[jovermier]

I tried running just using nhost up, which starts up fine in the Coder workspace. Then I run a React application where Coder handles subdomain-based port routing. The app is accessible at a URL like https://3000--main--<workspace>--<user>.coder.example.com/.

However, this setup doesn’t work with Nhost, as I’m seeing requests in the browser network panel going to https://local.auth.local.nhost.run/v1/token, which isn’t a publicly resolvable URL. Since this domain is only valid in the local development context, the app fails to authenticate correctly when accessed through Coder's URL.

[dbarrosop]

Please, read my previous messages and follow their instructions. If some instruction isn't clear feel free to ask, I will be happy to clarify.

[jovermier]

I create an example repo using devcontainer development environment as it uses a very similar approach to coder. This repo can be run locally or in GitHub Codespaces.

https://github.com/jovermier/nhost-vite

Currently I am trying to get nhost to run in the environment.

[dbarrosop]

I am not sure what to do with that repo, specially as I don't use/have any of the tools mentioned in the README. In any case, as mentioned in my previous message. To access your project on IP 1.2.3.4:

1. Run nhost up --local-subdomain 1-2-3-4-this-is-my-project
2. Configure the SDK to use that subdomain:

const nhost = new NhostClient({
  subdomain: import.meta.env.VITE_NHOST_SUBDOMAIN || "1-2-3-4-this-is-my-project",
  region: import.meta.env.VITE_NHOST_REGION || "local",
});

Demo

On my computer:

$ nhost --local-subdomain 192-168-1-103-proj-a up
Checking versions...
...
Nhost development environment started.
URLs:
- Postgres:         postgres://postgres:postgres@localhost:5432/local
- Hasura:           https://192-168-1-103-proj-a.hasura.local.nhost.run
- GraphQL:          https://192-168-1-103-proj-a.graphql.local.nhost.run
- Auth:             https://192-168-1-103-proj-a.auth.local.nhost.run
- Storage:          https://192-168-1-103-proj-a.storage.local.nhost.run
- Functions:        https://192-168-1-103-proj-a.functions.local.nhost.run
- Dashboard:        https://192-168-1-103-proj-a.dashboard.local.nhost.run
- Mailhog:          https://192-168-1-103-proj-a.mailhog.local.nhost.run

SDK Configuration:
 Subdomain:    192-168-1-103-proj-a
 Region:       local
Run `nhost up` to reload the development environment
Run `nhost down` to stop the development environment
Run `nhost logs` to watch the logs

On my phone, using https://192-168-1-103-proj-a.mailhog.local.nhost.run/:

[jovermier]

Your approach works if I run Nhost on a host machine and try to access it from another device over the network. However, it doesn't work inside a devcontainer using docker-in-docker.

I have updated my example project for the README to reflect working with more IDEs and simplified the doc. Hopefully you are using one of the IDEs in the list.

https://github.com/jovermier/nhost-vite

[jovermier]

I believe I have it fully working in my latest version. The key was to make the inner docker container privileged.

[jovermier]

I just tested running the devcontainer in codespaces. I can neither access nhost services nor the vite app access nhost backend while it runs in the cloud. Try running the project in GitHub Codespaces.