Caddy GUI

[mholt]

I would hate to forever limit Caddy's reach to those who can use the command line.

This issue is for discussing/brainstorming ideas for a graphical interface for Caddy. I'm open to any suggestions at this point.

My initial thoughts are for Caddy to launch a GUI in a browser tab if Caddy is run by double-clicking its icon in a file explorer. I also am thinking of a Mac DMG image for installing Caddy graphically and running it from Launchpad.

The web-based GUI would be relatively simple -- maybe, in its early days, even as simple as a text area for the Caddyfile to be edited. It would only be exposed to a special port on localhost and only if not run from the command line.

I am not sure yet if this would be built-in or a plugin; I can see advantages to either.

Also accepting UI mockups; I'll probably draft my own before too long.

[abiosoft]

This came to mind yesterday primarily because it will appeal to non programmers or "non-geeks" :)

I would prefer native desktop app but support for multiple platforms would be an additional concern. So, I'd vote for a webapp probably rendered with http://electron.atom.io/

What I have in mind is something with basic configurations and ability to start and stop caddy like MAMP/XAMP does for Apache.

[tpng]

Using electron seems a bit overkill considering the memory usage if they have to keep electron running together with caddy.

[My1]

so you plan a web-gui? I think a "normal" gui where you get options to start/stop the server, reload the caddyfile and other stuff, would be better but a gui would be epic anyway, true.

[incon]

I'm for launching the systems default browser for desktops to a web based configurator. Then a heavy solution like electron.

[DenBeke]

+1 for web-ui.

[unknwon]

+1 for a browser tab

[My1]

but why a browser tab? if caddy fails to start because of sime kinf os error it would be a lot easier to read the error in the gui instead of the cli (adding insult to injury in windows the cmd window cannot be made wider than a certain width making longer errors almost illegible.

[unknwon]

If Caddy fails to start, how does GUI connect to it?

Isn't GUI a client side thing..? Need some help to understand this approach.

[My1]

I rather thought that the gui doesnt connect to caddy but also that the gui starts caddy, and manages the stuff, a bit similar to the xampp-control gui.

[unknwon]

I rather thought that the gui doesnt connect to caddy but also that the gui starts caddy, and manages the stuff, a bit similar to the xampp-control gui.

Thanks, build sound like extremely high level of complicities to me...

[abiosoft]

The GUI will be the frontend for an app that will start caddy and direct the output to the GUI. It is independent of Caddy.

[unknwon]

The GUI will be the frontend for an app that will start caddy and direct the output to the GUI. It is independent of Caddy.

I suppose this is based the assumption of GUI and Caddy are both on local? How does it work when Caddy is on the remote?

[abiosoft]

Now I see your point. I was thinking in regards to local only.

I guess it is best we wait till Caddy API is ready. That way, there can be any type of client.

[mholt]

I've already got code that can open a browser tab at start. This would be for local only, and only when you click the icon from a file explorer (or specify a command line option, I guess). This GUI is simply an API client. I think @DenBeke is experimenting with a native Mac GUI that can start/stop Caddy independently; it's pretty neat.

If you're remote, you'd have to be using something like remote desktop and double-click the Caddy icon to start the GUI (or use the command line option to force opening the GUI).

I also plan to have a hosted web control panel for anyone to use that can connect - as long as you have credentials - to any publicly-facing Caddy server instance you control.

[My1]

but I would personally rather like an xampp style client which especially for ppl who just want to make their PC into a local server (for testing or whatever) this would be really helpful as you can put the text in a text field that you can resize with better linebreaks and stuff, especially since as I said windows cmd outtput is really hard to read if it gets longer than a line is, since there is no meaningful linebreak it just breaks at the last character and the width is limited.

[DenBeke]

I have already written a simple prototype, i.e. a native Mac apps which allows a user to launch Caddy with one click on a button.

The idea would be to add some very simple and rudimental options (like http port and directory) so people can quickly run a local webserver. (And optionally a text field where people can specify their own wanted Caddy directives)

If Caddy however comes with some (in that case cross platform) web-ui where people can configure everything, the native clients (like my Mac client) could become as thin as possible so we don't have to put a lot of effort in it.

To have a real local webserver where "noobs" can actually test their dynamic websites, we would also need bundle PHP and MySQL with those native clients (cfr. #376). This requires much more work since they are not just statically compiled binaries (like the Caddy executable) and people would most certainly not have all shared libraries that are needed.

[mholt]

I agree, we should coordinate the effort so that the native client can be extremely lightweight.

Hang tight, I gotta patch up some 0.8 stuff and then work will begin on 0.9, which is the API and GUI.

[ianwalter]

Forgive me if I missed it, will this be an add-on or part of core?

[mholt]

A simple GUI will probably be part of core, but it's still unclear exactly how this will be implemented.

[d1p]

how about an Electron App which uses nodejs child_process package to exec caddy commands? this way we can use existing caddy commandline with frontend sugarcoding.

[DenBeke]

how about an Electron App which uses nodejs child_process package to exec caddy commands? this way we can use existing caddy commandline with frontend sugarcoding.

That's what I already (partially) suggested. Once there is a webinterface for Caddy, it can easily be wrapped into a client.

[mholt]

I'm leaning more heavily toward just making Caddy's API really usable so that front-end clients can abound. So even though you're all welcome to build a nice, fancy GUI, the one that is built-in to Caddy (if any) will probably be small and simple (unless it's a plugin, which may include a more full-featured GUI).

[faddat]

@mholt @abiosoft @ozzadar

This seems like it could be very interesting when coupled with @abiosoft 's docker automation plugin. The GUI could literally contain buttons like "launch N". Funding source for Caddy: Install github.com/rancher/rancher do you see the diffferent cloud networks that one can launch rancher-agent instances onto? I'd bet $10 that Rancher gets a cut, and I see no reason at all that caddy could't get something very similar cooked into it, and I'd love to help that to happen however I can.

Oh, and the API concept (just making a really great API) is very solid, too.

[jungle-boogie]

@mholt, yes, a nice API would be best!

[hacdias]

Has anyone started this? I would like to start creating / help creating an web GUI / desktop GUI for caddy.

[mholt]

I wouldn't start until the API is flushed out; right now it's up in the air how things will work, and that may strongly influence the design of the UI.

[hacdias]

:+1:

[joanhey]

Please, don't make a web ui. It's 2016, we have a lot of servers, vps, ... and don't want to go from one web ui to another. We need a centralized client for all, that use the api.

For begin, a simple stop, start and add website. And a text-editor for config with syntax error, before save or send. So we can have local copies of configs, templates, ...

Something similar to http://blog.zhangruipeng.me/Hozz/ . Use electron, but can be any other platform, for sure the community will make a lot with electron.

That's only the beginning, this client app with app-indicator have infinite possibilities, that the community will make a reality via add-ons and push from the server.

Examples:

• view cpu, ram, hd, ... usage in server
• Make a local website backup
• send alerts
• profile apps
• etc

All from one client app, for all our servers. Actually we use several apps, for know the health of servers and web apps. This will change "It's 2016"

[mholt]

Thanks for the feedback @joanhey.

Please, don't make a web ui.

You wouldn't have to use it. Use some "all-in-one client" instead. But there absolutely has to be a way for non-technical folk to use caddy without having to drop to the command line, so I am already committed to it ;)

[danielsteiner]

Still, you can not use a built in web-gui when the server is not working. Including a configpanel into a product that is relying on a config file where dozens of things can go wrong is a bad idea. The approch of building a njs app that wraps around caddy is a good idea on the other hand - you can easily pass trough the caddy API and still use a great Native or Web UI.

[My1]

that's why I prefer a more native gui like xampp. by the way what is njs? if it's javascript wouldnt it be again browser only and rely on a server?

[mholt]

Including a configpanel into a product that is relying on a config file where dozens of things can go wrong is a bad idea.

Can you elaborate @danielsteiner? Why does this A) rely on a config file and B) can dozens of things go wrong?

Still, you can not use a built in web-gui when the server is not working.

What about it won't work?

[My1]

@mholt when your server oisnt running, how to run a webgui? this is like pulling the rug from under your feet. e.g. you cant run your controlpanel form windows if you somehow shot your windows down.

[mholt]

Ah, so working == running. You double-click the Caddy icon on your desktop to launch the GUI, for instance. Caddy will run in the background.

[My1]

but if the gui is a webgui there must be SOME server running to work with the webgui. else anything you try to send will go to /dev/null.

[mholt]

Indeed, Caddy will open a local port so it can serve the GUI.

[My1]

but unless you run the server twice (1 with the extra port for configuration and another one as the real server) you get to the point where a broken config kicks everything into oblivion and in that case a native Software would be better since it doesnt need to run all the time.

[danielsteiner]

Is there a way to ensure that the server will always start with at least the config ui?

[My1]

look above: use 2 instances. one for the gui stuff and one as the real server.

[mholt]

Two instances is not necessary. It will work nicely, I've already done a PoC. Do not worry. 😉

On Thu, May 19, 2016, 6:06 AM My1 notifications@github.com wrote:

look above: use 2 instances. one for the gui stuff and one as the real server.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/mholt/caddy/issues/350#issuecomment-220305015

[sinky]

I've build caddy-start using AutoIT for myself. A simple Tray App.

https://github.com/sinky/caddy-utils/tree/master/caddy_start < Old version. I'm try to update the Repo asp.

[nwgat]

neat @sinky useful to know if caddy is running

[danielsteiner]

Yup. Would be great to have a list with the vhosts though. Maybe i'll throw something together this weekend.

[thalesfsp]

@mholt It can be either a web-ui app and also and desktop app, so both sides are satisfied. It can start basic, MVP, but can evolve for something such as a button "Change to Advanced" where more Caddy aspects could be tweaked. I see securities needs in this case, nothing that an basic auth would not solve.

[mholt]

Alright, so 0.9 isn't the API and GUI like I thought it would be, but 0.10 should be; it's what I'll be working on after 0.9 is released stable. I've got enough feedback from this thread and a pretty clear vision of what I want to do at this point with regards to a UI, so I'll close this now. Feel free to continue the discussion though!

[ghost]

Is a configuration GUI in the core a dead idea now?

[mholt]

Not entirely, but it probably won't happen before 1.0. I updated the milestones lately to slate a GUI for the 2.0 tree.

[mervynsword]

Is the GUI still stay in the 2.0 tree? I am still waiting for this GREAT feature.

[mholt]

@mervynsword Probably at some point in the 2.x tree, but no immediate plans for an official GUI at this time. (We can expedite features for customers or higher-tier sponsors, however!)

[dkebler]

with caddy v2 having a built in rest api makes crafting a gui way easier. There could be an 'official' one but anyone could jump in.

The api is pretty basic and since the json data object is relatively small and singular it could easily be sent to the front end in its entirety to be edited/updated. One could even write a backend to isolate the actual api and allow it be run over a websocket which could allow for multiple users editing simultaneously since with socket push it would be possible to "lock" parts of the object tree if one client is currently editing them.

I personally use quasar/vue which can build electon and cordora apps as well as spa or pwa. That means one code for any os native app and always the web app as well. Because the structure of the json object will be fairly consistent/constant that will make it easy to code some nice caddy specific components.

Sure I can use the cli and/or coble together some quick UI of sorts with things like https://www.npmjs.com/package/got https://postwoman.io/?method=POST&url=https://httpbin.org&path=/get&contentType=application/json but for wider adoption some kind of UI will be the ticket. Caddyv1 has been great SO much better than nginx/apache to configure/use so V2 with a GUI would be supremo especially for any person/organization that needs a web server/proxy requiring frequent changes/attention.

https://quasar.dev/introduction-to-quasar