As a developer and business owner, I literally can't comprehend this response. I can't imagine idea of having to manage yet another server over running
ngrok http 8000 -subdomain=my-custom-subdomain
from the root of my application (which is wrapped in a single line shell script). For a business, paying $10/dev/month for ngrok is a rounding error.
This response only makes sense if you are not into DevOps, which I think you should as a developer. Take a random server exposed to the internet, use caddy or treafik to setup a reverse proxy. It takes like 20 seconds to create a reverse proxy to a random host connected via ssh.
Even easier, create predefined ports in caddy and connect to those via ssh. Assign domains to them like proxy<1-1000>.example.com. Connect to one via ssh that is free. Done. That's 2 seconds once it is setup.
Even easier and cheaper if you do not have a "random server exposed to the internet", take one of the alternatives shown by op which allows to deploy a digital ocean or Hetzner vm automatically. Done, like a few seconds from the command line.
10$ a month for something like this is over priced but I guess you prove that it is a valid business.
What you are describing is “easy” if it’s something you practice regularly. It would easily take me, an advanced SWE an hour to learn the process from scratch or re-learn after not thinking about the system for 18 months. $120/year pays for itself very quickly.
For anyone doing this as a hobby sure, but if this is your business then it’s nuts not to just pay the cheap toll.
But once you set it up - you've set it up for everyone on your team - you just add subdomains and keys to each person - which can be done by a script (depends on your DNS might require 1 manual step but you need this with ngrok anyway).
So it's not 120$/year - it's 120$/year/developer.
And setting it up for yourself - I've found multiple instances where having a configurable nginx reverse proxy on a public server saved me a bunch of time, it's much more flexible than ngrok.
If I have 100 devs that's $12,000/year (ignoring any bulk discount), right?
Are you saying that in a company with 100 developers they cannot spare enough time to run their own server cheaper than that?
Additionally, while the amount is 'cheap' in the isolated sense, when you start adding all those 'cheap' services together they quickly add up and suddenly your per-dev costs start getting out of control. In all cases you should consider the value of the service being provided. While I love ngrok, the functionality can easily be replaced for most use cases and move you from a per-dev cost to a relatively (yeah, large numbers of users will cause server scaling/cost changes) fixed cost instead.
Edit:
Just to add on, $10/month is more than I pay for Gsuite or Jira on a per dev basis. The Ngrok pricing is drastically off base IMHO.
What about something going wrong on ngrok's end and your hands being tied while nothing is working? Some might prefer similar solutions on servers that they control themselves.
Actually with WireGuard, OpenVPN and the like, you can do some pretty interesting (and sometimes problematic) things as well, so there's definitely a lot of flexibility with a few footguns here and there: https://blog.kronis.dev/tutorials/how-to-publicly-access-you...
Disclaimer: everyone's setup has their own requirements and whatnot. If using external services works for you, that's great! Also, that second article of mine may serve as an example of that NOT to do (you typically would only want to selectively forward ports, rather than forwarding all of the traffic like i did).
Yes but 1) I enjoy solving problems like this and 2) I’m not working and being paid for all that extra free time I have anyways. There is also a non-zero intangible cost to offloading all tasks. Based on your rationale a highly paid Google engineer would have a maid, chef, and Ikea furniture assembler and the only thing the guy would do is code all day because that’s the maximum value use of his/her time. Obviously most people do not do that. I’d probably pay up to $100 per day to a toilet paper monopoly so that I didn’t have to use my hands everyday. Luckily toilet paper isn’t in a monopoly situation, so I’m not going to hand over $100/day to Charmin even though that’s the value I get from their product.
But I think that point is moot because a service that costs $X in perpetuity must justify its costs with continuous new features and must be compared to alternatives. If I just wanted a basic proxy I’d run one of the open source alternatives in a container. If it required too much work, make a contribution to the project to make it easier for everyone. The value of ngrok is in its extra features, but the bulk of the cost is probably in setting up an actual VM and running it, which isn’t that hard these days and can be automated even in an open source offering. When considering the value of ngrok you can’t simply justify it by saying how much time it saves you. You have to compare it to the market, which includes free open source alternatives. So the real question to ask is whether the added features of ngrok plus the time savings over using some open source alternative is worth the extra cost over the time span I’d be using it. If time span is infinite, then maybe it makes sense to do a one-time extra cost of learning how to setup an open source alternative and paying a bit less for the actual VM costs. Maybe ngrok’s added features are indeed worth paying for. But telling yourself your time is not worth looking into this is a lazy justification for unnecessary subscriptions.
I've set this up for myself 4 years ago and it just works, having a nginx instance online was really useful many times, eg. just recently I had to setup custom routing rules for services configured on AWS load balancer, just setup the same routing rules on my nginx and tunneled my local services - spent 10 minutes to get a working environment for debugging on local machine - with ngrok I would need to setup a local reverse proxy and tunnel that, small time saver but there have been a lot of instances like this, where I'm like - oh let me just throw this on my garbage server to transfer, let's host it there for a demo, let me install code server there for a workshop, etc. It was there, running on my domain, I know how it's setup - much better value proposition than ngrok for the same price.
I also set it up for a team I worked with - took me 2 hours to get it running again and then the rest of the day to document and add keys for people and explain how and why they should use it. This was a team of 9 people - so in one day I did 1080$ - cost of small instance - for the year. That's above my daily rate so worth it for the owner as well.
10$/dev/month is not a lot - but this is such a trivial service that you setup once and forget, also there's a lot of friction in getting things like this approved and pretty much everyone has a some discretionary cloud provider budget.
> For a business, paying $10/dev/month for ngrok is a rounding error
Yes, but every tool on the wild wants you to pay 10 bucks per user per month.
github/gitlab, jira, random CI/CD tool, gitpod, private repo, tailscale/zerotrust, dockerhub, 1password, okta, notion...
Depending on your size, those costs can add up pretty quickly.
ngrok is a very low hanging fruit for keeping expenses at bay, 10 bucks per user is ridiculously expensive for the service they are providing.
This is great. Thanks for maintaining this artifact of pre-Web 2.0 days. And who knows, the next hot startup Jubyla may want to buy the domain for millions.
I love, love, love Postgres! The one feature MySQL has that Postgres doesn't is the ability to add a new column in an arbitrary position in the table. I like my tables to have a common "layout" and I would love to have this feature in Postgres.
If your data is tiny then within reason nothing matters, any popular database will be just fine. Where you care is precisely when your data gets big enough to be unwieldy.
I regularly deal with JSON documents several MB in size, but do developers frequently deal with JSON documents several GB in size? If so, where do you encounter something like that? Surely "processing" that much data (for whatever definition of process you have) is orders of magnitude slower than parsing it.
I love the idea of a library trying to squeeze every last bit of performance out of the CPU, but I'm genuinely curious at the problems it solves in the real world.
Depends. I've had multi-gigabyte `[{..}, {..}, ...]` json arrays from database dumps, and doing even basic things with that with jq takes ages unless you use the (highly obtuse IMO) streaming methods. Sometimes you can pre-grep to filter the results to something trivial to process, but sometimes the structure is not unique enough to let you do that, or it depends on multiple field values - filtering that with a json parser makes perfect sense, and then speed can matter.
That said, a 2x+ improvement for a couple megabytes, especially if done many times per second, is still a significant improvement.
Monthly general ledger entries for the largest real estate companies, tried XML and JSON, eventually landed on compressed CSV for best trade off between human readable large files (~1-3GB) and compressibility.
Not JSON, but we process XMLs on the order of a GB. Largest ones are consolidated invoices (ie a lot of separate invoices in one file). Other large ones contain rules and codelists in multiple languages.
All the time. It's not there's a single record that is that size, but all sorts of things log in json, so you wind up with multi-GB jsonl files. As an example: AWS CloudTrail logs.
Aren't log files processed a line at a time? Last time I had to deal with some structured log, I streamed lines concurrently into json parser and it went pretty fast.
The impact Vagrant has had on my business is nearly immeasurable (and for free, no less). We're a small startup, and I haven't had the time (or motivation) to learn what Docker, Kubernetes, containers, etc are. Seems overly complex.
But, virtual servers I can understand. I've been using Vagrant since 2013 and it ... just works. We've built our own custom box to standardize our development environment as well.
If there is one company and person I'd like to mimic, it's Hashicorp and Mitchell. Work to build an amazing product or products, get it ready for a sale or IPO, and then transition into an IC to continue doing what I love: hacking.
You can basically just treat it like a package manager and config-assistant. It's often easier(!) to configure a Docker image than the corresponding package, or set of packages, in your typical distro. In part this is because documenting where all the config files and data live just kinda falls naturally out of creating a half-decent image, and in part because good images often put commonly-modified config options—which may correspond to multiple changes in the config files—in single environment variables, for common use cases.
The main gotchas are making sure you've mapped any data directories to something outside the image (which is trivial to do with command-line options, if you prefer writing bash scripts, or in docker-compose yaml, and very easy to test—add some data, destroy the image, bring it back up, is your stuff there? Yes? Good, you got it) so data isn't lost if the image is replaced or destroyed, and making sure your port mapping isn't doing anything dumb like exposing ports it shouldn't on a public interface.
You don't have to use swarm or even actually learn how images work. You can run your application outside of it and just use pre-built official images from PostgreSQL, or whatever, and enjoy a nice, cross-distro, also-sorta-works-on-Mac-and-Windows, consistent set of project daemon dependencies, with an interface that's the same on Red Hat or Gentoo or Arch or wherever, and far more up-to-date than major stable distros (so you could use Debian Stable for simplicity and reliability, for example, but run the latest MySQL or ElasticSearch or whatever on it without mucking with the distro's packages).
I find this massively simplifies server config scripts (Ansible, or bash, or whatever) since I can confine those to fairly generic housekeeping things and put daemon config in much-tidier Docker scripts or yaml.
It's like git. You can get by for a while but when anything out of ordinary happens your understanding needs to go from 2% to 95% very quick. With apps that are really good at package management I fail to see need of docker. Ie node, and go lang.
Oh no, I practically never package my "app" with docker. I use it to install stuff like postgresql, and ensure it's at the same version & configured the same everywhere, regardless of the underlying distro (or even OS), using the same tools no matter where it's running.
It's often easier(!) to configure a Docker image than the corresponding package, or set of packages, in your typical distro.
My original reply was going to be something along the lines of "Bwahahahaha" followed by a comparison of how many seconds it takes to `pip3 install torch` vs how many hours you'd rip your hair out trying to get that running in Docker, let alone on a GPU, and let alone in a way that you can actually develop on it.
Perhaps it's easier to say, "We're not smart." Like Racket, Docker is a marvelous tool, and I'm sure a lot of smart people use it in some incredible ways.
I'll be 34 in Feb. Do I want to spend a month trying to force myself to use Docker for no apparent reason?
At my first job (gamedev), one of my coding heroes happened to work there. One thing he said really bugged me: "Shaders are a young person's game." By "hero" I mean that he single handedly wrote most of the Planetside 1 client code, as well as having developed many other titles that I grew up playing on MPlayer. (God help you if you know what MPlayer was.)
I tried explaining to him, no no, you see, it's not so bad! You can do it! I believe in you. Once you put in a little effort, you'll understand all the parts, and you'll see there's really not that much to it.
Yeah, uh, I was 19. He was like 40. I get it now.
I've personally deployed multiple services to production whose reliability can be measured in years: https://status.shawwn.com/
Sure, none of those are too impressive. Except the one I can't talk about, ha. But they're all variations on "get the server running, make sure the process is simple, make sure it's fail-safe, and put failsafes in place to notice if it breaks."
To my surprise, they almost never break. Isn't that marvelous? Here's me, someone inching closer and closer over the hill, delivering robust software that lasts years. Hell, you can even see for yourself: https://tags.tagpls.com/uptime
508d 00h 04m 14s
Not bad.
Sure, I'm being unfair. Because you'll rightly say that there's a world of difference between this and the situations DOcker's designed to solve.
And yet, as I go from company to company, I keep being surprised to find zero people using Docker. Isn't that strange? My wife just got a job at a YC co. I'll ask her whether anyone there uses Docker either. Maybe they do.
Docker's stolen days of my life for no gain. Painful days, because they were days when I was really into hacking, and I could've been busily building a big beaver dam instead of learning infrastructure that none of my colleagues ended up using.
Docker is a time vampire. It's "Nerd Snipe: The Game." You'll want to play with it, and it'll give you just enough happiness to keep you going. But, like a cat, the love is one-way. If Docker were a person, they would totally ditch you on your birthday.
It was much more satisfying to write this than to spend that time staring at yet another damn variation of "how do I forward the port properly?" torrent of blog posts from the legions of developers that Docker has managed to curse, by making the impressive decision to eschew simplicity in favor of being Smart with a capital-S.
But hey, Docker will be around longer than I will, I'm sure. So it'll get the last laugh. In seriousness though, you can get by without it, which is pretty remarkable -- almost as remarkable as it was to try out vagrant and discover that it's the polar opposite of Docker's philosophy.
The difference is easy to spot: Vagrant just works.
Oh no, I agree that it's not worth learning to package your "app" with docker that way unless you're planning to make it a big part of your processes, to reap the benefits.
It's just excellent for replacing other methods of installing & configuring daemons you're dependent on, especially if you're already in a "doing things wrong" kind of space (and hey, you and me both).
Very nearly all of my use of it doesn't involve modifying or customizing containers at all, and just lets me use one set of commands to manage packages across most platforms and pin them to my desired version without having to care much about the underlying OS, for dependencies like database systems, entire software packages that I don't need to modify aside from config (as in my personal use of it for things like Jellyfin and a Minecraft server), et c.
My server at home runs Debian Stable. Very little of what I use it for is available in the official repos at all. Docker, though? They're all available at the latest version, with a bunch of older versions available too, just as easily. And if I switch distros out from under them, or upgrade Debian, nothing happens. I just run the same stuff, and it works.
> And yet, as I go from company to company, I keep being surprised to find zero people using Docker.
Well that's pretty astounding. I work on a service at a Very Large Company that intercepts each docker container as it passes into our production-deployable repos and it inspects about 100 containers per hour. This isn't every build, it's every actual prod deployment. Mind you, we have lot of services doing deployments, but the ones that aren't using docker are in the vast, vast minority.
I think one thing docker brings you is consistency. At our level of scale, you can't be doing "pip install"s on random hosts or you'd never be able to say what state everything is in. Docker isn't the only way to do this, of course, but it's one way. And I'm super happy that other teams the produce tools built on piles of python now package them as docker containers on a standard base so I can just run them rather than spend a day untangle my completely-hosed python environment every few months.
