github-starred/go-http-tunnel

Fork 0

mirror of https://github.com/mmatczuk/go-http-tunnel.git synced 2026-05-15 14:16:17 -06:00

[GH-ISSUE #78] Cli more powerful #39

New issue

Open

opened 2026-05-05 10:58:08 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 10:58:08 -06:00

Owner

Originally created by @gianarb on GitHub (Mar 20, 2018).
Original GitHub issue: https://github.com/mmatczuk/go-http-tunnel/issues/78

Hello!
I love this tool but I don't like that much how the CLI interact with the daemon, I was using ngrok and its CLI is a bit more powerful.

I would like to propose some improvement that I would like to implement or maybe they are already there and I am not able to find them:

We should set up a configuration file for the CLI with a default location like ~/.tunnelctl/something to configure the tunneld target with client keys and so on. We can probably implement something like the profiles for the aws-cli
When we have that I would like to be able to start a tunnel via cli like `tunnel start --subdomain my 8080 (This will start my*.what.you.have* and it will forward port 8080)
If you don't specify a subdomain we can start a random one

I think this will cover a bit better some use cases, for example, I would like to use it during integration testing and the configuration file based interaction is not very comfortable.

Let me know

Originally created by @gianarb on GitHub (Mar 20, 2018). Original GitHub issue: https://github.com/mmatczuk/go-http-tunnel/issues/78 Hello! I love this tool but I don't like that much how the CLI interact with the daemon, I was using `ngrok` and its CLI is a bit more powerful. I would like to propose some improvement that I would like to implement or maybe they are already there and I am not able to find them: * We should set up a configuration file for the CLI with a default location like `~/.tunnelctl/something` to configure the tunneld target with client keys and so on. We can probably implement something like the [profiles for the aws-cli](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) * When we have that I would like to be able to start a tunnel via cli like `tunnel start --subdomain my 8080 (This will start my*.what.you.have* and it will forward port 8080) * If you don't specify a subdomain we can start a random one I think this will cover a bit better some use cases, for example, I would like to use it during integration testing and the configuration file based interaction is not very comfortable. Let me know

gitea-mirror commented

2026-05-05 10:58:10 -06:00

Author

Owner

@mmatczuk commented on GitHub (Mar 20, 2018):

Hi @gianarb

I love this tool but I don't like that much how the CLI interact with the daemon, I was using ngrok and its CLI is a bit more powerful.

Thanks, I'm happy to hear that.

I would like to propose some improvement that I would like to implement or maybe they are already there and I am not able to find them:

I believe that the default config file location should be there.

As for your proposal I'm in favor of of adding --subdomain, but it should be optional. The existing commands must remain functional. If you don't specify a subdomain then business as usual. Also user shall be warned when using this flag with tunnel name.

As for me I have a backlog of things I'd like to do with this project, CLI is one of them. My idea was to:

ship a single binary (tunnel server would start the server rest stays more or less the same)
use cobra (better help, bash completion)

@mmatczuk commented on GitHub (Mar 20, 2018): Hi @gianarb > I love this tool but I don't like that much how the CLI interact with the daemon, I was using ngrok and its CLI is a bit more powerful. Thanks, I'm happy to hear that. > I would like to propose some improvement that I would like to implement or maybe they are already there and I am not able to find them: I believe that the default config file location should be there. As for your proposal I'm in favor of of adding `--subdomain`, but it should be optional. The existing commands must remain functional. If you don't specify a subdomain then business as usual. Also user shall be warned when using this flag with tunnel name. As for me I have a backlog of things I'd like to do with this project, CLI is one of them. My idea was to: * ship a single binary (`tunnel server` would start the server rest stays more or less the same) * use cobra (better help, bash completion)

gitea-mirror commented

2026-05-05 10:58:11 -06:00

Author

Owner

@gianarb commented on GitHub (Mar 20, 2018):

@mmatczuk I 100% with you about about keeping the compatibility with what you have. It should now be hard and worst case scenario we can always to a different command like tunnel run .

Ok I am happy to read that you have the CLI in your todo list. I will try to code something soon

@gianarb commented on GitHub (Mar 20, 2018): @mmatczuk I 100% with you about about keeping the compatibility with what you have. It should now be hard and worst case scenario we can always to a different command like `tunnel run `. Ok I am happy to read that you have the CLI in your todo list. I will try to code something soon

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/go-http-tunnel#39

No description provided.

Rows
Columns