Biting the Docker/Caprover Bullet

I’ve only ever deployed things the easiest possible ways. For me, that has meant Django on heroku, basic python/flask serverlessly on vercel, and static (custom or Hugo) on Netlify/Cloudflare Pages.

But - being a devout hater of javascript, and wanting to stand up more complicated, multi-service applications, I knew the day would come when I would need to sit down and reckon with Docker.

I theoretically understand the value of docker, but my god is it a pain in the ass to learn. It adds a bunch of steps to everything, in addition to a bunch of extra loading time.

But it’s worth it, RIGHT!?

I know that once I learn to dockerize, deployment should be easier and more portable. I should technically be able to take the same containers and put them anywhere, at which point we’re just shopping for the best deals on VPS’s.

But then - where to start with that? Let’s be real, I’m a fan of baby steps where possible. I’m not going to sit down and start ssh-ing into my new VPS and start learning how to configure my own nginx and setting up my own cron jobs to keep my ssl up to date. Ain’t nobody got time to learn all that.

So what to do? Trolling around the interwebs essentially turns up CapRover and Dokku. CapRover has a GUI and some rave reviews (despite the apparent lack of zero-downtime deployments), so let’s rock.

♪ Drop-lets keep fallin’ on my head ♪

Supposedly places like Hetzner would offer more for less, but CapRover recommends starting on a $6 droplet on Digital Ocean, and they do seem to have the most hand-holdy, user-friendly experience, so that’s where we’re going. I feel like Heroku-to-droplet is a pretty common step, and let’s be real, the savings are enormous, even if I could only put one app on a droplet at a time (as opposed to cramming as many apps on that droplet as the resources would allow).

Of course, nothing went smoothly. Here, in no particular order, are all the things that had me pulling out my hair while learning all of this:

  • dockerizing fastapi - using the official fastapi docker tutorial wasn’t bad actually, but then learning the new workflow of actually running the app was a pain
  • write the Dockerfile, build the image, create the container/run, check the logs, debug, stop the container, remove it, rebuild, recreate, pull my hair out, smash my face into a wall, build the image….
  • figuring out that making calls from your frontend to your back end are going to need to change in your (gross) javascript functions - no more calls to localhost, now you’re making calls to 0.0.0.0:80 (or whatever’s in your Dockerfile)…until you figure out
  • that’s gotta be replaced with your actual deployed domain once you’re up and running
  • not to mention changing ‘ws:’ to ‘wss:’ if you’re doin’ websockets over HTTPS
  • setting up caprover, using their official ‘caprover deploy’ cli tool, not setting up a hardened subdomain, changing it from the dashboard, BREAKING EVERYTHING, deleting your droplet and starting over
  • realizing in shame that to deploy to CapRover you actually have to be tracking your code with git (which you were totally doing anyways…)
  • enabling websockets from your app’s dashboard, it not working, thinking you have to go into the main settings panel and manually configure nginx, realize it was something else screwing it all up and reversing all of that
  • and many, many more

On the bright side, and as painful as that all was - presumably now I can deploy whatever the hell I want to my own VPS whenever I want. That’s actually not a small deal, particularly given CapRover handles horizontal scaling with instances and has one click plugins for things like Postgres. I still have to figure things out like adding auth to Fastapi (this is where I miss Django), and swapping out one uvicorn worker for gunicorn with multiple uvicorn processes in the Dockerfile if/when I get any volume…but hey. A win’s a win. I’ll take it.

I don’t particularly look forward to swapping back and forth the domains in the front end api calls between developing locally and then deploying to production, and there’s probably a better way of doing it, but whatever. I’m new. Give me a break.

Anyways. Deployment solved for the foreseeable future. Hooray.

Alright alright alright

On a totally separate note, I’m listening to Matthew Mcconaughey’s book Greenlights and thoroughly enjoying it. It is pretty hilariously self-indulgent in a way that only he could get away with without coming off like an insufferable wacko, but the guy does seem a lot more intelligent and introspective than I expected. And there are some good lessons in there. Entertaining as hell, definitely recommend.

As far as the business - at this stage, I’m just rolling with where the opportunity seems to be. I keep making cool stuff, but my target audience (lawyers, at this stage) look at it, and while they’re impressed, they generally just say:

Can I just pay you to do it for me?

So what started as a legal tech tool company has quickly turned into a legal tech outsourcing company. Which is fine - there’s money, and lots of potential, but I’m not sure it’s as scalable a model. At this point though, I just need to get a viable business off the ground.

I’ll keep making the tools, if only because they let me do the outsourced work faster and better - maybe interest in licensing them will pick up. Either way, it’s nice to have a bit of a direction and some revenue.