i got zrok standard for the custom domains but i found nothing on the docs on how to forward to a custom domain or where to get one from pls help me here.
Hi @Proximity, welcome to the community and to zrok (and OpenZiti)!
There's no way to accommodate custom domains with the cloud-hosted version of zrok at zrok.io at this time. You can of course, self-host zrok and use any domain you wish. It's a common request, though, and very well might be something we look to enable in the future.
ok thanks for your help
Why does zrok.io advertise "Dedicated Custom Domain Name" for the standard plan if they can 't provide that? I'm glad I ran across this before paying for what you claim to sell, but it seems pretty surprising, and it would certainly have resulted in a refund request. I'm hoping I'm misunderstanding because I'd love to start the standard plan. It looks great and is affordable for hobby work.
Ugh. We jumped the gun listing this on the pricing page before the feature is released. I’ll make sure we correct the pricing page to be aligned with availability
Sounds good. I will probably check back on occasion to see if/when it's added back to the pricing page so I can sign up once it's ready. Thanks for the quick reply and the hard work!
1 Like
I'm also very interested in this feature. I can still see the Standard Plan listing "Private Network Option". Is that what we're talking about there or is that something else?
zrok.io today supports private shares: Private Shares | Zrok. A private share does not have a public address, and can only be accessed via zrok
zrok.io today supports reserved shares: Reserved Shares | Zrok. A reserved share lets you set the name of the share a client uses to access it. E.g., https://MYRESERVEDSHARENAME.share.zrok.io
We are currently working on a "dedicated custom domain" for the hosted zrok offering, which will allow you to configure your own custom replacement of the ".share.zrok.io" part of the URL
1 Like
This may have been brought up elsewhere, but I'll put it here again in case it's helpful...
Even with the free tier of zrok.io, it's very easy to to get ultra-cheap VPS hosting and run a zrok access private there. Combine that with a DNS entry for that host, and you've got a frontend with custom DNS... today.
In other words... zrok access private isn't just useful for workstations. Run it on a VPS or a container in the cloud and you've got an internet-facing gateway for your zrok share.
1 Like
Thanks for this clarity, @smilindave26. I'm a big plus one for dedicated custom domain.
1 Like
@michael.quigley Thanks for this. I suppose it's a way to make a private share public, but with a customisable alias. Nice.
One really nice feature of zrok public share is access control with oauth. If that were the use case, then your proposed VPS+DNS solution would need to have some auth layer somewhere. GCP has IAP, but I wonder what you might suggest?
Yeah. The best answer is for us to augment zrok access private to include the oauth components... that's not the immediate roadmap, but it's on the feature list once we're finally able to really dig into the v0.5 work.
In the short term you'd have to stick something in front of zrok access private. I'd bet you could get something like that working with Caddy pretty easily... In fact, that's probably what we'll do to incorporate more advanced features (like oauth) into the zrok access private server... we'll just embed Caddy.
It adds another piece of complexity to need to run an additional piece of software like Caddy... but I'd still bet one could spin up a tiny little micro-instance in the cloud and stick that proxy and zrok access private on it and have a nice little public bridge with custom DNS and such.
You could probably run a handful of zrok access private processes on a single instance... it's pretty lightweight. They could all go behind a single Caddy instance.
Obviously it'll all be much nicer when you can just click a couple of buttons in the zrok console and have the service take care of it for you... we're a small team and we're getting there as quickly as we can. Lotta work to do. 
I'll need to work out where Caddy fits in. I'm very new to zrok and OpenZiti - like started using zrok day before yesterday (I'm trying to replace ngrok). I've seen the example Caddy file in the frontdoor installation.
My particular use case is giving support users secure and access controlled connectivity to web portals running in several private environments. The support users are semi-technical at best (so zrok access private isn't really an option, unfortunately).
I could see Caddy running on a VPS delegating (demultiplexing) to several zrok share private, one for each web portal. And then as long as Caddy can implement the oauth, there is a solution.
Basically, you'd just stick it as a reverse proxy in front of zrok access private.
Yes, exactly!
This might be useful to get Caddy configured the way you want:
I bet there are similar tools for nginx if you preferred that to Caddy.
But yes... you'd basically be sticking a reverse proxy with authentication in front of a multiplicity of zrok access private instances (each of which is proxying through to a zrok share instance).
1 Like
Thanks for the pointers, @michael.quigley. I have the basics working now. Caddy running on a micro VPS proxying two localhost services (which will later be several zrok access privates), accessible using a subdomain of my own domain. Nice.
I'm now looking at oauth configuration, specifically using google. Seems like I need to install Caddy with a 3rd party module, e.g. greenpau/caddy-security. I've downloaded Caddy including that plugin and manually replaced /usr/bin/caddy (there must be a better way 
). Restarting with the new binary seems to work for the existing setup (without auth). So far so good.
I would find it really useful to have an example Caddy file which shows configuration for auth using Google for the greenpau/caddy-security plugin. Please let me know if you happen to know where I could find one. In the meantime I'm working through these,
@michael.quigley I've managed to get Caddy working with Google authentication reverse proxying a zrok private share. I took a while to get the Caddy stuff working, mostly because of the caddy-security plugin.
I've been using frontdoor (zrok-share) to run persistent public shares (with oauth). But it looks like frontdoor doesn't allow for private shares.
What is the recommended way to run long-running private shares? Perhaps @qrkourier has some good input on this.
@stefanadelbert Is Docker an option for you? I often run Caddy and zrok in Docker because it simplifies saving and remembering the various interdependent infrastructure and application configs as a handful of files in a single folder with Docker Compose.
That's the only way I can think of to do it with the zrok share examples we've published so far. Frontdoor was conceived for always-on public shares, and I can see the utility of a private share Linux service, too.
This example could be adapted for private shares or accesses or both. It uses a systemd feature to parameterize the service unit as a template for many service instances.
If it were my setup and I needed to run long-running private shares, and I didn't want to use containers... just processes on a host... then I would just write a simple systemd unit file for each of the shares that manages a zrok access private process.
You can get very fancy with systemd... but you can also keep it really basic.
@michael.quigley @qrkourier Thanks, chaps.
I had considered a custom systemd unit (borrowing heavily from zrok-share), but then baulked at having to maintain and distribute that unit.
@qrkourier Thanks for the link to the systemd unit post using templates. I wasn't aware of that functionality - that's really neat.
I use docker compose extensively in other parts of the system, so this does seem like a cleaner option for me.
Something like,
- a
zrok share privateservice added to the docker compose of each of my private endpoints - a new docker compose on the public-facing proxy (Caddy) running services for
zrok access privatefor each private endpoint- caddy (google oauth, reverse proxy for each private share)
I've had a look at the compose files in the zrok repo. I got the zrok-private-share one working easily. But I don't see an example for reserved private shares, which I need for this use case. Looks like I'd need to modify one of those compose files to add a reserve step. This is a little tricky because zrok reserve private ... isn't idempotent. I'd need to mimic what frontdoor does for reserved shares or even use zrok-share.bash for the functionality. And then we've come full circle.
This is going to need some more thought and time from me. There is definitely a good solution here somewhere. Thanks for the help.
Excited to follow along with what you share.
Also know that we're working as fast as we can to improve the overall zrok experience and provide more of these kinds of capabilities out of the box for you. It's coming... but we're just a small scrappy team going as fast as we can.