# Sidekiq Published articles for Sidekiq. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Why Gusto hired Evil Martians for Sidekiq infrastructure DevFeed: [Why Gusto hired Evil Martians for Sidekiq infrastructure]() Original publisher: [Read original article]() Author: Irina Nazarova (inazarova@evilmartians.com) Published: 2026-09-02T00:00:00Z Content type: article Language: en Sources: [Evil Martians]() Topics: [Sidekiq](), [Rails](), [Redis](), [Ruby]() Tags: [ai](), [case-study](), [engineering](), [infrastructure](), [rails](), [redis](), [ruby](), [scale](), [sidekiq]() ### AI overview This case study examines why Gusto hired Evil Martians to work on the Sidekiq and Redis infrastructure supporting background jobs in its large Rails monolith. It discusses the operational demands of running payroll-related jobs at scale and the tradeoffs involved when a company uses consultants instead of waiting for a perfect hire. ### Source excerpt Gusto runs payroll for 500,000+ businesses on one of the largest Rails monoliths anywhere. Why a team this strong hired Evil Martians for Sidekiq at scale, what running background jobs at that size actually takes, and when to stop waiting for the perfect hire. ## Fair by design: orchestrating background jobs in Ruby DevFeed: [Fair by design: orchestrating background jobs in Ruby]() Original publisher: [Read original article]() Author: Travis Turner (richardturner@evilmartians.com) Published: 2026-08-11T00:00:00Z Content type: tutorial Language: en Sources: [Evil Martians]() Topics: [Ruby](), [jobs](), [Latency](), [autoscaling]() Tags: [autoscaling](), [how-to](), [jobs](), [latency](), [performance](), [rails](), [redis](), [ruby](), [sidekiq]() ### AI overview This tutorial examines fairness in Ruby background-job processing. It explains how queue latency affects quality of service, why adding workers or autoscaling may be limited by shared resources and operational cost, and introduces background-job prioritization as a way to address bottlenecks. ### Source excerpt Are you treating your users fairly? They could be stuck in the queue while a greedy user monopolizes resources. And you might not even know it! In this post, you'll see if it's time for you to take background job prioritization seriously, and how to make it fair for all users. ## A Pre-Deployment Checklist for Risky Data Migrations DevFeed: [A Pre-Deployment Checklist for Risky Data Migrations]() Original publisher: [Read original article]() Published: 2023-09-13T00:00:00Z Content type: tutorial Language: en Sources: [Artsy]() Topics: [Command-line interface](), [Docker](), [Kubernetes](), [Sidekiq](), [Latency]() Tags: [command-line](), [data-migrations](), [deploy-process](), [docker](), [error-reporting](), [kubernetes](), [latency](), [logs](), [migrations](), [retry](), [ruby-on-rails](), [sidekiq]() ### AI overview This article presents a pre-deployment checklist for risky data migrations and other changes that could affect production services. It recommends planning rollback steps and monitoring error rates, reported errors, latency, logs, functionality, and failing Sidekiq retries after deployment. ### Source excerpt Lately, I've been getting involved with some sketchy stuff. You know what I'm talking about-data migrations. I've been rolling out changes that have a significant risk of breaking our production environment for mission-critical services. It's been exciting work (keep your eyes out for more posts on the exact project, coming soon™), but I've definitely caused a couple incidents along the way. After accidentally taking down a key service for a couple hours, I decided I needed to have a better pre-deploy process for these changes. I did some thinking and came up with a short checklist to run through before I press the shiny green button. Here's the checklist I came up with: What is your plan if something goes wrong? Run through ramifications of rolling back. If there's a reason you're worried about rolling back, then you're not ready to deploy the change yet! Figure out exactly what command(s) you will need to run to roll back. At Artsy, this is usually a one-liner using Hokusai, our command-line Docker/Kubernetes CLI How will you tell if something is going wrong after you deploy? Error rate (DataDog) Specific error reporting (Sentry) Latency (DataDog) Logs (Papertrail) Functionality (does it still work? Are people using it successfully? Important for things where errors may not be bubbled up correctly or reported immediately) Sidekiq (are there lots of jobs queued to retry that are failing?) With this checklist in hand, I'm deploying more confidently and causing fewer incidents along the way. Do you have something similar? Are there things you think this checklist should include? Let me know in the comments! ## Introducing Simplekiq: A Lightweight Orchestration Framework for Ruby DevFeed: [Introducing Simplekiq: A Lightweight Orchestration Framework for Ruby]() Original publisher: [Read original article]() Author: Doximity Published: 2023-05-03T11:28:00Z Content type: article Language: en Sources: [Doximity]() Topics: [Orchestration](), [Sidekiq](), [Ruby](), [Framework]() Tags: [declarative](), [orchestration](), [parallel](), [refactoring](), [ruby](), [sidekiq](), [workflow]() ### AI overview The article introduces Simplekiq, a lightweight Ruby workflow framework built on Sidekiq Pro batching. It presents declarative, single-file orchestrations with serial and parallel execution as a way to make complex background-job workflows easier to understand, diagnose, and refactor. ### Source excerpt Sidekiq is an amazing background job framework for Ruby with a long history of the best kind of minimalism - one of performance and succinctness. However, a downside of this is that long workflows built from dozens of background jobs queueing subsequent background jobs can be difficult to consistently design and maintain. We especially struggled with refactoring these types of structures since one has to read through all the code for the jobs to understand when and from where each job might get queued. The added complexity of manually defining Sidekiq Pro batches leads to difficult-to-diagnose triage in more creative workflows, especially when batch callbacks are involved. Introducing Simplekiq: A Solution to Our Challenges We solved our issue by building Simplekiq (special thanks to Daniel Pepper for freeing the rubygems simplekiq name for us) --a lightweight background job workflow framework built on top of Sidekiq Pro batching. Simplekiq solves the issue of having to follow long chains of jobs that queue other jobs ad nauseam. Workflows that span many files and job classes are inherently difficult to understand, diagnose and refactor. Simplekiq flattens out these complex, multi-file workflows into declarative, single-file ones which we call orchestrations. Each orchestration can contain a mix of serial and parallel execution so that even the most complex workflow can be expressed in an efficient, readable syntax. Comparing Sidekiq Pro and Simplekiq with an Example It's easier to demonstrate this with an example: making an apple pie. The late, great Carl Sagan taught us that to make an apple pie from scratch we must first invent the universe. That's a bit out of budget for most bakeries, but in the spirit of simplicity let's explore how a workflow for baking an apple pie from basic ingredients looks in standard Sidekiq Pro structures and compare it to the flattened Simplekiq paradigm. Our example will also show how refactoring differs between the two. Implementing ## 5 SRE tips for Rails workloads in Kubernetes DevFeed: [5 SRE tips for Rails workloads in Kubernetes]() Original publisher: [Read original article]() Author: Doximity Published: 2022-12-02T13:00:00Z Content type: article Language: en Sources: [Doximity]() Topics: [Kubernetes](), [Rails](), [Deployment Strategies](), [Kafka](), [Sidekiq](), [site-reliability-engineering]() Tags: [bugs](), [deployment](), [deployment-strategies](), [kafka](), [kubernetes](), [performance](), [rails](), [sidekiq]() ### AI overview The article presents five changes made to Kubernetes clusters to better support Rails workloads and workflows. The supplied text focuses on deployment strategies: RollingUpdate is used for web traffic, while Recreate is used for Kafka and Sidekiq workloads because RollingUpdate caused rebalancing, performance, and compatibility issues during deployments. ### Source excerpt In a previous post we shared some suggestions for how to adjust a Rails application to make it run better in a containerized setting. In this post I'd like to explore the opposite relationship: five changes we have made to our Kubernetes clusters to better accommodate Rails workloads and workflows. All of these ideas can be relevant to non-Rails apps too! Selecting the right deployment strategies The two deployment strategies Kubernetes offers out of the box are RollingUpdate or Recreate. Initially we selected RollingUpdate for all of our workloads; with this strategy some new pods are created before old ones are terminated. The RollingUpdate strategy is ideal for our web traffic because if Kubernetes shuts down all of the existing pods before it starts up any new pods, users will see 5XX errors until the new web pods are healthy, not good. That said, the RollingUpdate strategy created issues with our Sidekiq and Kafka workloads so we switched those to use the Recreate strategy. Looking at Kafka first, consumers are basically just a group of processes working together to handle messages. Kafka consumers follow a rebalancing protocol when a new member wants to join a consumer group. During deployments we encountered bugs and performance issues while using RollingUpdate approach because new pods kept trickling-in and wanting to join the consumer group therefore triggering multiple rebalances. Switching our Kafka consumers to deploy using the Recreate strategy means all the existing Pods get killed before any new pods get created. This results in much more predictable deployment behavior, and now we see only a single rebalance with all new consumers joining the group at basically the same time. Next, looking at Sidekiq, it does not stop workers from processing jobs when a new worker process joins, so we didn't have quite as many issues with using the RollingUpdate approach. However, it did occasionally cause subtle bugs on some deployments. For example, if a team creat ## Square Payroll's Migration from a Monolith to Microservices DevFeed: [Square Payroll's Migration from a Monolith to Microservices]() Original publisher: [Read original article]() Author: Harold Sultan Published: 2022-10-12T04:00:00Z Content type: article Language: en Sources: [Square Corner Blog](), [Square Corner Blog RSS Feed]() Topics: [Microservices](), [migration](), [Amazon Web Services](), [Serverless](), [serverless architecture](), [Architecture & Design](), [Ruby](), [MySQL](), [Sidekiq]() Tags: [architecture](), [aws](), [engineering](), [microservices](), [migration](), [mysql](), [ruby](), [serverless](), [serverless-architecture](), [sidekiq]() ### AI overview Square describes an early step in migrating Square Payroll from a Ruby monolith backed by MySQL to a more scalable architecture. The article focuses on redesigning its tax filing system with AWS serverless architecture and using a Step Function to reduce code complexity and improve transparency. ### Source excerpt Scaling with AWS serverless architecture ## To Thread or Not to Thread: An In-Depth Look at Ruby's Execution Models DevFeed: [To Thread or Not to Thread: An In-Depth Look at Ruby's Execution Models]() Original publisher: [Read original article]() Author: Jean Boussier Published: 2022-05-31T14:00:00Z Content type: article Language: en Sources: [Shopify Engineering](), [Shopify Engineering - Shopify Engineering]() Topics: [Ruby](), [Concurrent Programming](), [Processes](), [web applications](), [Rails](), [Sidekiq](), [Heroku]() Tags: [heroku](), [processes](), [rails](), [ruby](), [sidekiq](), [thread](), [threads](), [web-applications]() ### AI overview This article examines threaded servers and processes in Ruby web applications. It explains why threads are a popular default, compares their throughput and memory characteristics with processes, and discusses static and request-processing memory, garbage collection, and Copy on Write. ### Source excerpt An in-depth look at threads vs processes in Ruby web applications, and when you should use each. ## Logster and our error logging strategy at Discourse DevFeed: [Logster and our error logging strategy at Discourse]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2019-01-02T07:11:20Z Content type: article Language: en Sources: [Sam Saffron]() Topics: [log management](), [Logging](), [Ruby](), [Ruby on Rails](), [Open Source](), [Redis](), [Sidekiq](), [Grafana](), [nginx](), [Prometheus](), [Docker]() Tags: [backend](), [blog](), [c-sharp](), [docker](), [errors](), [grafana](), [logging](), [logs](), [monitoring](), [net](), [nginx](), [open-source](), [production](), [prometheus](), [rails](), [redis](), [ruby](), [ruby-on-rails](), [saffron](), [sam](), [sidekiq](), [sql](), [visibility](), [weblog]() ### AI overview The article describes Discourse's logging strategy and Logster, an open-source log viewer for Ruby on Rails or Rack applications. It explains how Logster stores and analyzes logs with Redis, aggregates production errors, and provides detailed development logs, alongside broader monitoring and observability tools. ### Source excerpt I have always been somewhat fascinated with logs. I tend to see the warning and error logs in production as a valuable heartbeat of an application. Proper handling of error logs is a very strong complement to a robust test suite. It shows us what really happens when real world data meets our application. 9 years ago, at Stack Overflow we had a daily ritual where we would open up our fork of ELMAH every morning and fish through our logs for problems. This had a dramatic positive effect on Stack Overflow. Almost 7 years into our journey building Discourse, every single week we find and fix issues in our application thanks to our error logs and Logster. Error logs are the pulse of our application, they let us know immediately if there are any urgent issues and where. Since we host more than 1500 sites running many different code branches, we needed to evolve a sane and robust set of practices and tools. Top level structure of logging and monitoring at Discourse We have lots of logs at Discourse and many systems for dealing with them. We keep raw Docker, Postgres, Redis, NGINX, Rails and HAProxy and so on in Elastic Search and use Kibana for business intelligence. We have a monitoring system built on alertmanager and Prometheus, with business intelligence in Grafana and alert escalation in our internal Discourse instance and opsgenie. We have logster which we use for web application aka. "Rails / Sidekiq" warnings and errors. I would like to focus on logster and our Rails / Sidekiq portion for this blog post, but think it is worth mentioning other mechanisms cause I don't want people to think we are not good data hoarders and only have very limited visibility into our systems. About Logster At Discourse we developed a log viewer called logster. Logster is a free and open source tool you can embed into any Ruby on Rails or Rack application in production and development. It runs as Rack middleware and uses Redis as its backend for log storage and analysis. It operates in ## Finding where STDOUT/STDERR debug messages are coming from DevFeed: [Finding where STDOUT/STDERR debug messages are coming from]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2018-08-07T06:06:55Z Content type: tutorial Language: en Sources: [Sam Saffron]() Topics: [debug](), [Development](), [servers](), [Sidekiq]() Tags: [blog](), [c-sharp](), [console](), [debug](), [debugger](), [development](), [net](), [rails](), [ruby](), [saffron](), [sam](), [server](), [sidekiq](), [sql](), [weblog]() ### AI overview A debugging tip for tracing unexpected messages printed to STDOUT or STDERR in development. The article shows how to reopen STDERR and attach a method that prints caller locations when write is invoked, helping identify the source of stray output in web servers, test suites, or upgraded gems. ### Source excerpt Recently, we have been experiencing "stalls" in the Puma web server in development, this means that quite often during our dev cycle we would hit CTRL-C and be stuck waiting many many seconds for Puma to stop. Sometimes needing to fallback to kill -9 on the Puma process. We definitely want this Puma issue fixed, however our "web application server of choice" is Unicorn not Puma. It makes little sense for us to run Puma in development. Our Unicorn configuration is very mature and handles all sorts of magic including automatic forking of our Sidekiq job scheduler which is awesome in dev. A major problem though is that when we run Puma in dev our console is pristine, run Unicorn in dev and it is noise central. 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/pretty-text-bundle.js?1533620338.6222095 HTTP/1.1" 200 112048 0.0481 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/plugin.js?1533620338.6222444 HTTP/1.1" 200 146176 0.0726 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/plugin-third-party.js?1533620338.6222594 HTTP/1.1" 200 3364 0.0569 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/application.js?1533620338.6222193 HTTP/1.1" 200 3039095 0.2049 127.0.0.1 - - [07/Aug/2018:15:38:59 +1000] "GET /assets/fontawesome-webfont.woff2?http://l.discourse&2&v=4.7.0 HTTP/1.1" 304 - 0.0016 I am a puts debugger and being barred from being a puts debugger in development is a blocking feature for me. So, how do we find where these messages are coming from? Before we start the little tip here first... if you have not yet... take a break and read _why's classic seeing metaclasses clearly. Now that you know about metaclasses, time to have some fun, let's reopen STDERR and glue a little debug method to it that will output caller locations when we invoke write on STDERR (note this will work on STDOUT as well if you want): class << STDERR alias_method :orig_write, :write def write(x) orig_write(caller[0..3].join("\n")) orig_write(x) end end /home/sam/.rbenv/v ## Debugging 100% CPU usage in production Ruby on Rails systems DevFeed: [Debugging 100% CPU usage in production Ruby on Rails systems]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2018-01-18T02:24:25Z Content type: tutorial Language: en Sources: [Sam Saffron]() Topics: [Ruby on Rails](), [Ruby](), [debug](), [systems]() Tags: [debugging](), [performance](), [production](), [ruby](), [ruby-on-rails](), [sidekiq]() ### AI overview This article explains how to investigate 100% CPU usage in a production Ruby on Rails system. It demonstrates using rbtrace and stackprof with Sidekiq to capture CPU profiles, identify the code consuming the processor, and analyze the resulting performance data. The reported culprit is a regular expression in Typography.to_html_french. ### Source excerpt Today I noticed one of our customer containers was running really high on CPU. # top -bn1 190 discour+ 20 0 2266292 205128 15656 S 86.7 0.3 9377:35 ruby # ps aux discour+ 190 19.4 0.3 2266292 207096 ? Sl 2017 9364:38 sidekiq 5.0.5 discourse [1 of 5 busy] Looks like sidekiq is stuck on a job. Where is it stuck? Usually, this is where the story ends and another series of questions start Can we reproduce this on staging or development? What code changed recently? Why is perf trace not giving me anything I can work with? How awesome is my Sidekiq logging? Where is my divining rod? Julia Evans is working on a fantastic profiler that will allow us to answer this kind of question real quick. But in the meantime, is there anything we can do? rbtrace + stackprof At Discourse we include rbtrace and stackprof in our Gemfile. gem 'rbtrace' gem 'stackprof', require: false We always load up rbtrace in production, it allows us a large variety of production level debugging. stackprof is loaded on-demand. In this particular case I simply run: # rbtrace -p 190 -e 'Thread.new{ require "stackprof"; StackProf.start(mode: :cpu); sleep 2; StackProf.stop; StackProf.results("/tmp/perf"); }' This injects a new thread that enables stackprof globally and finally writes the performance data to /tmp/perf This dump can easily be analyzed: # stackprof /tmp/perf ================================== Mode: cpu(1000) Samples: 475 (0.63% miss rate) GC: 0 (0.00%) ================================== TOTAL (pct) SAMPLES (pct) FRAME 473 (99.6%) 473 (99.6%) #::Typography.to_html_french 4 (0.8%) 1 (0.2%) #.reap_connections In fact, we can even collect backtraces and generate flamegraphs in stackprof, so I strongly recommend reading through the readme. So there you have it, my culprit is: text.gsub(/(\s|)+([!?;]+(\s|\z))/, ' \2\3') A regular expression consuming 100% CPU in production, this has got to be a first ## Writing a one-time script in Rails DevFeed: [Writing a one-time script in Rails]() Original publisher: [Read original article]() Author: Justin Weiss Published: 2017-02-14T06:08:51Z Content type: tutorial Language: en Sources: [Justin Weiss]() Topics: [Rails](), [Script](), [data](), [migration](), [import](), [CSV](), [Database]() Tags: [capistrano](), [csv](), [data](), [database](), [heroku](), [import](), [job](), [migration](), [other](), [rails](), [rake](), [scheduler](), [script](), [sidekiq](), [structure]() ### AI overview This Rails tutorial explains how to handle one-time data tasks, comparing database migrations with rake tasks and scheduled background jobs. It recommends rake tasks for code that must be tested locally and run in production, while noting when migrations are appropriate and what risks model changes can create. ### Source excerpt Have you ever wanted to import a bunch of data into your app from a CSV file? Or maybe you need to fix badly encoded characters in some of your customer reviews. Or you changed your mind about how you wanted to store data in Redis, and had to move everything from the old format to the new one. At Avvo, we called these "ad-hoc tasks." As in, you probably only need to run them once. So what's the best way to handle an ad-hoc task in Rails? Write a database migration A migration works well if you need to change the structure of the data in your database. It tracks whether the task was run, it carries over changes to other environments - it's what migrations were built for. It's also what you're probably already using them for. If you're changing data at the same time, a migration might work well. But there are some things to watch out for. Calling something like Permissions.create(...) in your migration can cause you trouble. If the model has changed, your migration might break, because your model might not be available when the migration runs. Or your model might have changed between the time you wrote the migration and when it ran. There are ways to get around this, but they're error-prone and can fail in weird ways. Migrations are also less useful if your task doesn't involve ActiveRecord. These aren't deal-breakers. But I tend not to import or change much data in migrations. There are better options. Write a rake task You have a task. You probably only want to run it once. And you want to be able to test it on your machine and run it in production. Rake tasks work really well for this. Rails can even generate rake tasks for you: $ be rails g task locations import create lib/tasks/locations.rake This creates a file for you to stash your code into: lib/tasks/locations.rakenamespace :locations do desc "TODO" task import: :environment do end end Inside that task block, you can use all your models and the rest of the code in your Rails app. It's easy to import and chang ## Optimum Sidekiq Configuration on Heroku with Puma DevFeed: [Optimum Sidekiq Configuration on Heroku with Puma]() Original publisher: [Read original article]() Published: 2015-12-08T02:49:47Z Content type: article Language: en Sources: [Jolly Good Code]() Topics: [Sidekiq](), [Heroku](), [configuration]() Tags: [configuration](), [heroku](), [sidekiq]() ### AI overview The article presents an optimum configuration for running Sidekiq on Heroku with Puma. ### Source excerpt What's the optimum config for Sidekiq on Heroku with Puma? Check out our config! ## Debugging memory leaks in Ruby DevFeed: [Debugging memory leaks in Ruby]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2015-03-31T06:44:39Z Content type: tutorial Language: en Sources: [Sam Saffron]() Topics: [Memory Leaks](), [Ruby](), [debug](), [Rails](), [Grafana](), [Docker](), [Processes](), [Monitoring]() Tags: [debugging](), [docker](), [grafana](), [memory-leaks](), [metrics](), [process](), [rails](), [ruby](), [sidekiq]() ### AI overview A practical guide to diagnosing memory leaks in Ruby and Rails applications. It recommends graphing memory over time, tracking RSS for key processes such as Unicorn and Sidekiq, and examining memory-growth trends across Docker containers. ### Source excerpt At some point in the life of every Rails developer you are bound to hit a memory leak. It may be a tiny amount of constant memory growth, or a spurt of growth that hits you on the job queue when certain jobs run. Sadly, most Ruby devs out there simply employ monit , inspeqtor or unicorn worker killers. This allows you to move along and do more important work, tidily sweeping the problem snugly under the carpet. Unfortunately, this approach leads to quite a few bad side effects. Besides performance pains, instability and larger memory requirements it also leaves the community with a general lack of confidence in Ruby. Monitoring and restarting processes is a very important tool for your arsenal, but at best it is a stopgap and safeguard. It is not a solution. We have some amazing tools out there for attacking and resolving memory leaks, especially the easy ones - managed memory leaks. Are we leaking ? The first and most important step for dealing with memory problems is graphing memory over time. At Discourse we use a combo of Graphite , statsd and Grafana to graph application metrics. A while back I packaged up a Docker image for this work which is pretty close to what we are running today. If rolling your own is not your thing you could look at New Relic, Datadog or any other cloud based metric provider. The key metric you first need to track is RSS for your key Ruby processes. At Discourse we look at max RSS for Unicorn our web server and Sidekiq our job queue. Discourse is deployed on multiple machines in multiple Docker containers. We use a custom built Docker container to watch all the other Docker containers. This container is launched with access to the Docker socket so it can interrogate Docker about Docker. It uses docker exec to get all sorts of information about the processes running inside the container. Note: Discourse uses the unicorn master process to launch multiple workers and job queues, it is impossible to achieve the same setup (which shares memo ## Discourse as my blogging platform DevFeed: [Discourse as my blogging platform]() Original publisher: [Read original article]() Author: Sam Saffron Published: 2013-10-10T10:44:37Z Content type: article Language: en Sources: [Sam Saffron]() Topics: [Rails](), [Code](), [Digital Ocean](), [Sidekiq](), [GitHub]() Tags: [blogging](), [code](), [digital-ocean](), [email](), [github](), [integration](), [plugin](), [rails](), [sidekiq]() ### AI overview The author describes moving a blog into Discourse by building a Discourse plugin with Rails engines. The post also discusses hosting on DigitalOcean and experimenting with Rails, Unicorn, Rack Hijack, Sidekiq, and email integration. ### Source excerpt This Blog has gone through several incarnations. When I started blogging I used subtext. Then I decided it was time to reinvent wheels and rolled my own, hodge-podge, blogging solution. It worked ok, but I found I had extreme difficulty engaging with the community. People would leave replies and I had no idea if they ever got my response. Further more creating content was becoming a huge pain. I ended up using the Discourse editor for some posts and then pasting the body of the post here. Crazytown. So I had this idea, what if I could have Discourse turtles all the way down. I took some time to extend our plugin story and using the magic of Rails engines managed to host my blog inside Discourse. You can see the full source code of this blog as a Discourse plugin at: GitHub - SamSaffron/blog: samsaffron.com blog plugin for Discourse I am hosted on Digital Ocean (a 2GB instance). I am also experimenting with some less traditional Discourse configs: I am running Rails 4 I am running unicorn, with Rack Hijack to handle long polling I am running no bluepill, I tricked unicorn into daemonizing sidekiq and use an upstart job. Let's see how it goes. All of this and more deserves a much more detailed blog post. Before any of this, let me address the elephant in the room. Commenting on this blog just became way more complicated. I plan to address that, in a future update, this is a temporary state. I want to bring back the traditional commenting box. That said, I have email integration set up, so now when I respond to you, you will get an email you can respond to. You will not even need to visit this site to spam my blog Overall, I am super excited about this. It pushes the limits of what can be done with Discourse and leaves breadcrumbs for others to follow. More to come, now that blogging became so much easier.