Request queue time and some updates

I hope you’re well! Autumn is in full swing in Ohio, and I’m loving it.

Here’s the latest from my world of Heroku & Rails Autoscale:

  • RubyConf & t-shirts

  • Request queue time deep dive

  • Language-agnostic autoscaling

RubyConf & t-shirts

I’ll be at RubyConf in Denver next week, showing off our the Rails Autoscale shirt.

(selfies are so stressful 😂)

If you or someone you know is going to be there, please say hello and get a shirt!

Request queue time deep dive

My latest post on the Rails Autoscale blog goes deep into the importance and nuance of “request queue time”. If you’re at all responsible for running a production web app, I think you’ll find it helpful.

Check it out and LMK what you think!

Language-agnostic autoscaling

Rails Autoscale is getting a complete overhaul, and the flagship feature is language-agnostic autoscaling. We’re currently onboarding early-access users. If you run a non-Ruby app—or even if you want to explore the new autoscaler with a Ruby app—let me know.

Tools for your Heroku apps

Hi there!

We’re nearing the end of summer here in Ohio, and I’ve got a few quick things to share with you.

First, I’m currently working on a language-agnostic autoscaler for Heroku. Rails Autoscale was built specifically for Ruby on Rails, and I’ve had many folks ask me about autoscaling their apps written in Node, Python, and more.

Do you have a non-Ruby Heroku app in production? Please reply and let me know. I’d love to talk to you.


I recently created a free tool to help you configure your app: the Heroku Database Connection Calculator.

Use this tool to avoid database connection errors and optimize your database pool configuration. Let me know what you think!


Did you know you can run real-time aggregations on your Heroku logs from the command line?

That’s just a taste from my latest blog post, Power tools for analyzing your Heroku logs. This article dives deep into Angle Grinder, one of my favorite command line tools.


That’s all for now. Take care!

–Adam

Using Heroku for free

Hello there. It’s been a while, and I have a couple quick updates for you.

On the blog…

I recently published a completely (almost) rewritten guide on how to use Heroku for free. I wrote the original guide in 2019, and I intended to give it just a little update for 2021. I got a bit carried away, though. It’s much more extensive (and useful!) than the original.

If you’re looking to run a side project for free (or at least very cheap), this guide will help.

On the business…

Rails Autoscale was accepted into the TinySeed 2021 Spring batch! TinySeed is the “first accelerator designed for bootstrappers”, which means it’s time to ACCELERATE! 😁

Really, what it means is that I’m now focused full-time on Rails Autoscale, writing, screencasting, and other sharing (like this newsletter). Maybe it won’t be almost a year between posts now. 🤷‍♂️

This is a whole new chapter in my life and business. I’m grateful for your support (just hitting that subscribe button is a vote of confidence), and I’m super excited for what’s to come.

See you next time!

–Adam

How many Heroku dynos do you need, and which size?

I’m emailing you because you signed up to receive Heroku tips from me. If you’re no longer interested, hit the unsubscribe link below. No hard feelings. :-)


Hi there! I just published my first blog post in over a year, and I’m super excited to share it with you.

I’ve been working on this one for a while, and I’m quite proud of the result: How many Heroku dynos do you need, and which size—An opinionated guide.

One thing I didn’t mention in the article is what type of dyno I use myself to run Rails Autoscale. Don’t tell anyone, but I actually use Standard-1x dynos, which I recommend against in that post! 😬

Since I’ve kept the app extremely lightweight, it consumes less memory than any other Rails app I’ve worked on. This puts Rails Autoscale is in the minority of Rails apps that can run on a 1x dyno with two Puma workers—a requirement I lay out in the post.

I felt it would be a bit distracting to include that in the article, but I needed to get it off my chest… 😆

I hope you give it a read, and let me know if you do! I plan to continue updating it, so I welcome any feedback or suggestions. If you’re feeling generous and want to share it on Twitter, Reddit, Slack, or wherever you talk tech, that would be awesome as well. ❤️


That’s it for now.

Thanks for following my journey. Take care of yourselves!

—Adam

Pipelines for solo devs

Mastering Heroku newsletter

It's spring in Ohio! I'm still flying high after attending MicroConf a few weeks back, and I'm wrapping up the [largest Rails Autoscale feature](https://twitter.com/adamlogic/status/1110142400566083585) I've added since launch. Exciting times. 🔥

My emphasis this spring/summer will be on writing—on Twitter, on railsautoscale.com, and in this newsletter. So here goes...

Let's get back to Heroku and talk about Pipelines. It's recently come to my attention that many folks who are using Heroku are NOT using Pipelines. 😱

Let me be clear about my position on this: I think EVERY Heroku app should be using Pipelines. I can't think of a single scenario where it doesn't provide some benefit.

If you're unfamiliar, Heroku Pipelines are a groups of apps that share the same codebase, such as a staging and production app. Pipelines provide tooling for promoting code between these environments and automatically creating review apps for GitHub pull requests. I'm not going to talk about how to create and use Pipelines, because the docs do that very well.

Oh, did I mention Pipelines are FREE?!

The argument I hear against Pipelines is along the lines of "I'm a solo dev working on one feature at a time, so I don't need review apps". Fair enough. I'm also a solo dev on Rails Autoscale, but I still love Pipelines. Here's why...

  • I'm often pushing code and walking away from my computer. As a solo dev, it's important that I'm at my computer for a prod deploy in case anything goes wrong. I want prod deploys to be an intentional act, not a side effect of pushing to master. (I this goes against continuous deployment. I'm a huge fan of frequent deployment, but I'm not quite ready for continuous.)

  • I want prod deployments to be instant. Waiting for a build process is too much friction. Promoting staging to production using Pipelines is incredibly fast because it doesn't rebuild your app—it just copies the compiled slug.

  • The Pipelines UI has a lovely "compare on GitHub" button to review the exact changes that will be deployed to production.

Here's my workflow in a nutshell:

  • Small changes are pushed directly to master. For larger features I'll work in a branch until I'm ready to merge.

  • All changes on master are automatically deployed my staging app on Heroku. I use Codeship to run CI, but I do not wait for CI to pass before deploying to staging. Since it's just me, I'd rather have the speed of a faster staging deploy. If I break something on staging, I'll just fix it on the next commit. Not a big deal.

  • None of this impacts production. I can push complete garbage to master, and at worst I'm left with a messy commit history and a broken staging environment. I can live with this.

  • When I'm ready to deploy to prod, I promote staging through Slack using Heroku ChatOps. I could just as well do it through the CLI or Pipelines GUI.

That's it. My complete solo dev workflow. It's low friction, low stress, and completely enabled by Pipelines.

Thanks for reading!

BTW, if you're on Heroku and not using Pipelines, I'd love for you to reply and let me know what I've overlooked. 😊

Loading more posts…