8000 Configurable Ports for Dashboard and Mailhog · Issue #967 · nhost/cli · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Configurable Ports for Dashboard and Mailhog #967

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
jovermier opened this issue Jun 7, 2025 · 7 comments · May be fixed by #968
Open

Configurable Ports for Dashboard and Mailhog #967

jovermier opened this issue Jun 7, 2025 · 7 comments · May be fixed by #968

Comments

@jovermier
Copy link
jovermier commented Jun 7, 2025 •
edited
Loading

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
@jovermier jovermier linked a pull request Jun 7, 2025 that will close this issue
Open
@dbarrosop
Copy link
Member

Hi, this is already possible via the http flag.

@jovermier
Copy link
Author

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
Copy link
Author
jovermier commented Jun 7, 2025 •
edited
Loading

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

@jovermier
Copy link
Author

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

@dbarrosop
Copy link
Member
dbarrosop commented Jun 9, 2025 •
edited
Loading

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
Copy link
Author

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
Image

@dbarrosop
Copy link
Member
dbarrosop commented Jun 12, 2025 •
edited
Loading

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: configurable ports for dashboard and mailhog jovermier/cli
2 participants
@dbarrosop @jovermier
0