High-performance, low-latency apps are table stakes now. Users expect things to be fast, and budgets no longer support just throwing money at the problem. In modern high-throughput, resource-constrained environments, every byte and every millisecond matters. And the database is often the biggest leverage point.

Rails and SaaS apps often stumble in the same predictable ways: UUIDv4 keys, wide tables, and bloated indexes keep showing up, adding latency and cost as data grows.

In this post, I’ll cover five common Postgres anti-patterns I see in production Rails setups, and what to do instead.

1. Using UUIDv4 as Primary Keys

Why it’s a problem

Because UUIDv4 is completely random, every insert lands in a different place in the index. That randomness forces Postgres to spread keys across way more pages than necessary. More pages means more I/O and more shuffling to find records that match a query. Even if you throw all the RAM in the world at it, UUIDv4 still forces the database to work harder, and the performance hit is real, even if it’s not always obvious or easy to trace.

What to do instead

• Use BIGINTs. They support up to 9 quintillion values, more than enough for anything a Rails app will ever need. They’re also compact (just 8 bytes) and naturally sequential, so inserts tend to land on the same page. That means fewer page splits, faster inserts, and better performance for lookups and range scans.
• If you really need globally unique IDs, use UUIDv7. They’re time-ordered, so new records tend to land on the same page or the next sequential page. They use 16 bytes (twice the size of a BIGINT), so you’re paying more in storage, but you still avoid the page explosion problem of UUIDv4.

2. Ultra-Wide Tables

Why it’s a problem

Tables with lots of columns hurt performance in a few ways.

First, there’s the obvious cost of pulling all that data. It still has to come off disk, travel over the network, and get instantiated into large in-memory objects. Second, even when you’re not querying everything, Postgres still has to manage all those extra columns. TOAST (Postgres’s system for handling large field values) adds more I/O, more CPU work, and more complexity. And finally, the queries themselves get huge and unreadable. Most slow query logs won’t even capture the full text, which means the part of the SQL that could actually help with indexing or optimization is lost.

What to do instead

• The best fix is to split the table. Keep the core attributes in one table and move the sparse or optional fields into another, connected with a has_one relationship. That way most queries only touch the smaller table, and you only hit the larger one when the app actually needs those extra fields.
• If you’re stuck with a wide table, be deliberate about which data is selected. Use methods like pluck or pass an explicit column list to select to avoid pulling back more data than needed. This won’t fix the schema, but it will reduce payload size and help maintain faster response times.

3. Letting Indexes Get Big and Slow

Why it’s a problem

In PostgreSQL, every update or delete leaves behind dead index entries that don’t get cleaned up right away.

On high-churn tables like delayed_jobs, solid_queue_jobs, and good_jobs, indexes grow fast and lose efficiency quickly. A query that took 2 ms with a fresh index can be crawling at 20 ms only a few hours later. As those dead entries accumulate, the index gets spread across more pages than necessary. That means more pages to scan, more random I/O, higher memory usage, and more CPU time spent navigating bloated index trees.

What to do instead

• Run REINDEX CONCURRENTLY regularly on high-churn tables to rebuild indexes. Reindexing clears out dead entries and helps restore index efficiency and performance.
• For very large or heavily read indexes, consider using pg_repack. Like REINDEX CONCURRENTLY, it rebuilds indexes without blocking reads and writes, but it does so in parallel, which results in a smaller online performance hit. The trade-off is that it requires temporary disk space roughly equal to the size of the index.
• Track index health regularly. The pgstattuple extension provides detailed metrics on density, making it easier to identify when an index has become inefficient and needs reindexing.

4. Storing Statuses as Strings

Why it’s a problem

Storing statuses as plain text like 'pending', 'shipped', or 'canceled' feels easy and flexible. You can add new states whenever without too much work. I made the same mistake, encoding 'up' and 'down' states as strings in httpscout.

The problem with storing statuses as text is that the data isn’t dense. Strings use more bytes than necessary to represent a small, fixed set of states. That extra size makes rows bigger, indexes less efficient, and forces Postgres to push more data through disk and memory than it needs to. Multiply that overhead across millions of rows, and it adds up to a real performance cost.

What to do instead

• Use a small integer column to encode statuses. It’s a denser representation that requires less storage and keeps rows and indexes smaller. In Rails, you can use an enum to keep meaningful names:

class Order < ApplicationRecord
  enum status: { pending: 0, shipped: 1, canceled: 2 }
end

This gives you human-readable statuses in the app code, while the database stores them in a more compact and efficient form.

5. Leaving Around Dead and Unused Indexes

Why it’s a problem

In Rails, it’s easy to add indexes. We’re taught to be proactive and treat them as free. But every index has a cost.

Whenever a record is inserted, updated, or deleted, Postgres has to update every relevant index, even the ones no queries are using. As the number of indexes grows, write performance gets worse. I’ve seen p90 insert times jump from sub-millisecond to over 15 ms, purely because of how many indexes the table had. That’s time your web thread is blocked, stuck waiting on Postgres instead of handling the next request.

What to do instead

• Track index usage over time. If Postgres hasn’t used an index for a reasonable period, drop it.
• In Rails, you can use RailsPgExtras to surface unused indexes. If an index has zero scans and isn’t unique, it’s probably safe to drop.

Conclusion

PostgreSQL can be incredibly fast, but only if you use it with care. These anti-patterns show up quietly: one UUID primary key, one index, one column at a time. Before long, the app slows down, queries drag, infra bills grow, and the app spends more and more time waiting on the database.

Performance isn’t magic. It’s the result of small, intentional decisions that add up over time: lean tables, healthy indexes, and regular maintenance. In high-throughput systems, those details make all the difference.

Notes, Links, and References

1. PostgreSQL UUID Performance: Benchmarking Random (v4) and Time-based (v7) UUIDs
2. UUIDv7: The Time-Sortable Identifier for Modern Databases
3. Estimating Bloat of Tables and Indexes
4. PostgreSQL Wiki - Index Maintenance
5. Using pg_repack to Rebuild Indexes
6. Performance Implications of TOAST
7. Rails PG Extras

I would avoid potential problems with sharing the database later, didn’t have to worry about auto-increment overflow, eliminated the risk of leaking sequential IDs that could allow record enumeration attacks, and took a tiny bit of pressure off the database by generating IDs in the app instead of the DB. I thought I was clever.

That feeling lasted until we onboarded our first major client. Suddenly, queries against UUIDv4-keyed tables were slow “work_mem set to 1KB” slow. No matter how carefully we indexed, we couldn’t get the same performance we were used to with traditional keys.

The core problem is that UUIDv4 values are completely random, so inserts land all over the key space. This blows up index locality, forcing the B-tree to constantly split and rebalance. Pages end up half-full and scattered, which means fewer of them stay resident in memory.

UUIDs are also 16 bytes, double the width of a BIGINT and quadruple an INTEGER, so every index entry and table row pointer has more overhead. That extra width also means fewer entries per page, more pages overall, and more cache churn. Once those pages fall out of shared buffers, Postgresql has to hit disk to read them back, and query latency spikes.

Something else I learned, important enough to call out separately, is that signed BIGINTs support values from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. That’s over 9 quintillion IDs. Auto-increment exhaustion is simply not a realistic concern for most applications. It’s not a good reason to choose UUIDv4.

In the end, we re-keyed everything to use BIGINT. Performance returned: smaller indexes, faster writes, and query times that made sense again. The fix worked, but it came at the cost of weeks of worry and re-work. The takeaway was clear: if you can avoid UUIDs, do it.

What About UUIDv7?

UUIDv7 indexes better than UUIDv4, but back when I made this mistake, UUIDv7 didn’t exist. If it had, I might have made a different choice.

V7 embeds a millisecond-precision timestamp into the UUID, which means inserts are monotoniclly increasing instead of fully random. You still get globally unique identifiers but also have less spaced out indexes. This results in better insert performance, smaller indexes, and faster selects. These are all the properties you want for a high-performance index.

Benchmarks back this up, with tests showing UUIDv7 insert performance up to 30–35% faster than UUIDv4, producing indexes around 22% smaller, and yield a 54% reduction in query execution time on Postgresql.

Closing Advice

Avoid UUIDv4 for primary keys unless you truly have no alternative. The performance hit is real. If you can use BIGINT, do it. It’s faster, more compact, and you’re not running out of IDs in your lifetime. Also, there are some good human-readable ID libraries out there too if you want something nicer looking IDs. If you need IDs generated outside the database, across shards, or in a distributed system, then UUIDv7 or ULIDs.

Some recent conversations touched on building a culture of reliability. This post explores one piece of that: practice.

Practice Before It Breaks

Being on call is tough. It’s stressful. The page comes in, adrenaline spikes, and you’re scrambling. It’s not a fun time.

One way to make that stress manageable is to practice. If you’ve never walked through a restart, or an alert, or a login issue before it breaks then of course you’re going to freeze when it does.

Drills give you a chance to interact with the system and figure things out while it’s still calm. You simulate fire ahead of time, so when the real thing happens, you don’t panic. You’ve seen what happens and you have an idea of what to expect.

Practice in Pieces

Not every drill needs to simulate a catastrophe. Some just walk through a single action—loading a dashboard, restarting a service, deploying a config. Others mimic real-world pressure: a customer hammering on a dashboard, a long-running cron job, or support backfilling data.

That kind of mess is what actually causes most incidents. Not the infrastructure itself, but the messy edge cases—customers doing unexpected things, real load, application-layer bugs.

And while you can walk through the steps it’s better to actually perform them and see what really breaks.

Practice in Prod

Staging environments are incomplete representations of production. There’s rarely enough data, and logging and alerting usually aren’t fully wired up. But if that’s where you feel comfortable starting, that’s fine. Start there.

Eventually, though, you’ll want to practice in prod. Nothing beats production. It’s where you learn how an incident really unfolds.

Plan Your Practice

A drill isn’t supposed to be a surprise. No chaos monkey please, we don’t need more stress. So schedule the drill, pick a scope, and let other teams know what you’re doing.

Other Benefits

There’s more to practicing than just not panicking during an incident. Drills are also a way to bring people into the team, to share language and techniques, and to build camaraderie.

They’re also one of the simplest ways to share institutional knowledge (because no matter how much you document, some of it just lives in people’s heads). And sharing that builds trust – it helps people feel like they belong.

Conclusion

Practice doesn’t solve everything. But it lowers panic, surfaces the unknown, and builds trust.

I’ve written elsewhere about operational reviews, and there’s more to say about observability, operability, and performance. This post focuses on practice, specifically, the benefits of practice.

This post is a work in progress. I’ll keep expanding and refining it over time.

Most Rails performance problems aren’t about Ruby. They’re about data: how it’s accessed, serialized, cached, and moved through your system.

These are practices I’ve picked up from running Rails in production. Some are obvious, others less so.

🗃️ Data First, Always

Your database is the bottleneck long before Ruby is.

• Avoid N+1 queries. Yes, still.
• Use exists? instead of count > 0.
• Use pluck to avoid loading columns you don’t need.
• Never call .all. Use pagination library or chunking with .in_batches instead.
• For massive tables, consider partitioning especially for time-based data.

Indexing

• Composite indexes should reflect your actual query filters and sort order.
• Use partial indexes to address query skew and workload imbalances. If a single tenant generates the majority of reads on a table, create a targeted index for just their slice of data. This avoids full-table indexes and keeps read performance fast for high-traffic accounts.
• Too many indexes will slow down inserts and updates—index only what you read often.
• Monitor slow queries and experiment with different indexes.

🟥 Redis

Redis gets abused and forgotten.

For caching Redis, reduce how often data is written to disk. Optimize save and appendonly settings. If you overload a single Redis instance, you’ll experience weird latency spikes.

• Split workloads:
  • One Redis for jobs (Sidekiq)
  • One for caching (Rails.cache)
  • One for ephemeral features (rate limiting, feature flags, etc.)

🦵 Sidekiq Queues & Concurrency

• More queues = more polling, more complexity, more starvation risk.
• Sidekiq latency problems are often queue starvation or Redis slowness, not job logic.
• Tune concurrency to match job intensity. CPU-bound work needs fewer threads.

💾 Cache Aggressively

The less work your database has to do, the faster everything else gets.

• Use HTTP caching where applicable.
• Cache HTML fragments for common UI blocks.
• Cache expensive queries and API responses.
• Use jsonapi-serializer for fast, structured JSON. It’s composable and cache-aware.
• Make sure you have TTL entries on your cache items.

🌊 Pool Sizes & Throughput

Puma, Sidekiq, Postgres, Redis—they all have pool settings. If they’re misaligned, you’ll see weird timeouts and throughput drops.

• Configure Postgresql and Redis’ connection pool size to RAILS_MAX_THREADS + 1.
• Higher thread and worker counts can overwhelm your database. Experiment.
• Monitor wait times in your connection pools. They’re early indicators of saturation.

🚀 Ruby & Gems

Ruby performance matters, but it’s not the first lever.

• Ruby 3.5 is faster. Use it.
• Enable YJIT. It’s real now.
• Use jemalloc.
• Configure MALLOC_CONF to reduce memory fragmentation with jemalloc.

Before tuning code, audit your gems:

• Avoid gems that wrap everything in callbacks or monkey patches.
• Avoid gems with inefficient data access patterns—they don’t scale.

🛰️ Still to Come

• Memory pressure and tuning for large multi-tenant workloads.
• Strategies for load testing with vegeta.
• Notes on replicas, analytics traffic, and write isolation.
• Horizontal scaling basics: how and why to split workloads across differently configured hosts.

Something’s clearly broken in my setup. It’s something I’ll fix one day. Right now I don’t have the brain juice. That said, I still want performance. A 1.9MB bundle is oppressive (and embarrassing), even with HTTP caching.

Anyhoo, I was reading ruby.social, and pushcx published a bug list for lobste.rs.

And! as luck would have it, one of the issues referenced using gzip_static in nginx.

I immediately understood what I saw. I know I didn’t have that set, and it would make serving the giant js file faster.

It’s a simple change to the nginx config:

location ~ ^/(assets)/ {
  gzip_static on;
  root /home/rails/lrt/current/public;
  expires max;
  add_header Cache-Control private;
}

Before And After

Before enabling gzip_static, the JavaScript bundle was 1.9MB, the CSS was 548KB, and total transferred size came out to 2.6MB. Finish Time was 990 miliseconds.

After the change, the JS dropped to 672KB, CSS to 72.4KB, and total transfer came down to 816KB. Finish time fell to 440. That’s 550 miliseconds faster!

Conclusion

Enabling gzip_static took 550 ms off Finish Time and reduced the total payload by 1.7MB. That’s a single-line nginx config change with a huge payoff. The asset pipeline still needs work, but this gave the site the performance boost it needed.

P.S.

I’m grateful that sites like ruby.social and lobste.rs exist.

It’s deceptively simple, but incredibly useful. The idea is: move formatting and conditionals out of the view and into a plain Ruby object. That keeps logic in one place and makes the view easier to read.

I once shared it with a colleague, and they were genuinely blown away. Hopefully, you’ll find it just as useful.

An unrefactored mailer view

This view has some issues that make it a good candidate for refactoring:

• It uses inline date formatting (strftime) right in the template.
• It calculates days_left directly inside the view logic, tying it to Date.today at render time.
• It contains conditional branching that controls not just structure, but wording.
• It handles pluralization manually: "day#{'s' unless days_left == 1}".

Hi <%= @user.name %>,

Just a reminder that your book "<%= @book.title %>" is due on
<%= @book.due_date.strftime("%B %d, %Y") %>.

<% days_left = (@book.due_date - Date.today).to_i %>
<% if days_left <= 2 %>
  Please return it as soon as possible.

  It's due in just <%= days_left %> day<%= 's' if days_left != 1 %>!
<% else %>
  You still have <%= days_left %> day<%= 's' if days_left != 1 %> left.
<% end %>

Thanks,

Your Friendly Library

Same logic, cleaner view

The refactor moved the conditionals, formatting, and pluralization out of the view and into a new presenter class. The result is a clean template with no conditional logic or formatting.

Hi <%= @presenter.user_name %>,

Just a reminder that your book "<%= @presenter.book_title %>" is due on <%= @presenter.due_date %>.

<%= @presenter.return_message %>

Thanks,

Your Friendly Library

How to get there

The new presenter class.

class BookDueSoonPresenter
  attr_reader :user, :book

  def initialize(user:, book:)
    @user = user
    @book = book
  end

  def user_name
    user.name
  end

  def subject
    "Reminder: Book Due Soon"
  end

  def book_title
    book.title
  end

  def due_date
    book.due_date.strftime("%B %d, %Y")
  end

  def days_left
    (book.due_date.to_date - Date.today).to_i
  end

  def return_message
    messages.fetch(message_key) % { days: pluralized_days_left }
  end

  def message_key
    days_left <= 2 ? :urgent : :friendly
  end

  def messages
    {
      urgent:   "Please return it as soon as possible — it's due in just %{days}!",
      friendly: "You still have %{days} left."
    }
  end

  def pluralized_days_left
    "#{days_left} #{'day'.pluralize(days_left)}"
  end
end

Instantiating the presenter in the mailer.

class UserMailer < ApplicationMailer
  def book_due_soon(user, book)
    @presenter = BookDueSoonPresenter.new(user: user, book: book)
    mail(to: user.email, subject: @presenter.subject )
  end
end

Testing Before vs After

Before the refactor, testing required parsing rendered email output with string matching or regexes — a fragile way to verify logic.

test "return_message is urgent when due in 1 day" do
  user = User.new(name: "Shey")
  book = Book.new(title: "Dune", due_date: Date.today + 1)

  email = UserMailer.book_due_soon(user, book).body.to_s

  assert_includes email, "it's due in just 1 day!"
end

After the Refactor: test the presenter directly instead of the view.

test "return_message is urgent when due in 1 day" do
  user = User.new(name: "Shey")
  book = Book.new(title: "Dune", due_date: Date.today + 1)

  presenter = BookDueSoonPresenter.new(user: user, book: book)

  assert_equal "Please return it as soon as possible — it's due in just 1 day!", presenter.return_message
end

It works the same way in controller views as it does in mailers — anywhere you have complex logic in templates.

Hope you found it helpful.

Update (May 2025): I later refactored this presenter once the logic started to grow. You can read about that here.

The service file: /etc/systemd/system/docker-prune.service

[Unit]
Description=Daily Docker System Prune
Wants=docker.service
After=docker.service

[Service]
Type=oneshot
ExecStart=/usr/bin/docker system prune -f --filter "until=720h"

[Install]
WantedBy=multi-user.target

The timer file: /etc/systemd/system/docker-prune.timer

[Unit]
Description=Run Docker System Prune Daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Enable the service and timer

sudo systemctl daemon-reexec
 sudo systemctl enable --now docker-prune.timer

Confirming it’s working

List active timers:

systemctl list-timers --all

Check the logs:

journalctl -u docker-prune.service

It runs once a day like it’s supposed to. The logs are easier to read, and the files are easier to edit. So yeah, no more cron.

RUN gem install bundler -v 2.6.7 && \
  bundle config set --global gem.rdoc false && \
  bundle config set --global gem.ri false && \
  bundle install --no-cache

It seemed reasonable: skip the docs, avoid the cache—build faster and ship smaller images. But I never actually tested whether these settings made a difference. Until now.

Bundling with local caching enabled and with rdocs: 87.8 seconds.

Bundling without local caching enabled and without rdoc: 89.7 seconds.

Build time? Basically the same. There’s some variability—public internet and all—but for Ruby, there’s no appreciable difference

Image size? Identical in both cases: 4.57GB.

And yes, I’m using Debian (Bookworm), which isn’t exactly slim–but that’s not the issue. The config flags I copied–the ones I believed made a difference–didn’t. They didn’t speed up the build. They didn’t shrink the image. I had assumed they would.

Turns out Bundler doesn’t generate docs during bundle install–it delegates installation to RubyGems, which skips documentation unless you explicitly ask for it. So all those extra flags like gem.rdoc and gem.ri? They don’t do anything. They just look useful.

Same with --no-cache, it sounds like it prevents .gem files from being stored in /usr/local/bundle/cache, but it doesn’t! That cache is created by RubyGems fetching gems before installation.So, if you want to reduce image size, you have to remove them manually.

RUN gem install bundler -v 2.6.7 && \
  bundle install --no-cache && \
  rm -rf /usr/local/bundle/cache/*

And there you have it—finally, a smaller image.

I’d been cargo-culting these flags for years. They didn’t speed anything up. They didn’t shrink the image. And now I’m here, confessing my sins. I hope this helps someone.

1. Letter Opener Web – Easy Email Debugging

Email’s annoying to debug. Letter Opener Web just opens it in the browser. You see what you sent, no risk of it hitting a real inbox, no guessing on formatting. It shortens the loop and saves time.

2. Ahoy – First Party Analytics in Rails

With analytics come: privacy concerns, GDPR, and monthly bills. Ahoy just logs events locally. It’s simple, Rails-native, and works without bringing in another service. It gives me enough insight to improve flows without the overhead.

3. Exception Track – Tracking Exceptions Without Using Yet Another Service

Exception Track. It does what it says. Exceptions show up in a readable view—no parsing logs, no external service, no accounts. I don’t need anything fancy, just visibility when something breaks. Exception Track handles that and gets out of the way.

4. Invisible Captcha – Blocking Bots Without Annoying Users

I don’t like captchas. They’re friction. With Invisible Captcha, there are no puzzles, no weird image grids. It catches bots without annoying real users. It’s great.

5. Lograge – Structured Logging FTW

I self-host HTTPScout, so I’m already reading logs. Lograge outputs structured JSON, which makes it easier to filter and debug with jq or grep. It’s not fancy, but it works. Also lines up well with upcoming Rails 7.2 logging changes.

Final Thoughts

These gems save me time. They reduce noise, cut out external dependencies, and let me stay focused. Most are free. None require yet another account. If you’re trying to keep things simple, these might help.

In this post, I want to share the nginx config and the customizations I use for my Rails apps. While the config isn’t perfect, it’s been reliable in production and handles traffic spikes well. There are a few quirks, but overall it’s a solid setup that has worked for me.

Rate Limiting

I use a dual-zone approach to rate-limiting that doesn’t completely prevent DoS attacks but helps mitigate the risk of cascading failures during legitimate traffic surges. The per-second limit absorbs brief spikes without blocking users, while the per-minute limit manages sustained high traffic.

##################################
## Rate limiting Zone Definition
##################################
limit_req_zone $binary_remote_addr zone=zone_request_limit_second:10m rate=4r/s;
limit_req_zone $binary_remote_addr zone=zone_request_limit_minute:10m rate=120r/m;


##################################
## Rate limiting
##################################
limit_req zone=zone_request_limit_second burst=8 nodelay;
limit_req zone=zone_request_limit_minute burst=180 nodelay;
limit_req_status 429;

Avoiding Sending Unnecessary Traffic to Rails

Since Nginx is much faster than Rails at serving static assets, I configure nginx to handle those requests directly. And by filtering out certain types of traffic at the Nginx level, I avoid sending requests to Rails that it can’t process. This keeps the app responsive, even during traffic spikes.

# Avoid sending unnecessary requests upstream to the app.
location ~ (\.php|\.aspx|\.asp|myadmin) {
  return 404;
}

# Serve robots.txt, favicon, etc., directly from nginx
location ~ ^/(robots.txt|sitemap.xml.gz|favicon.ico) {
  root /home/rails/lrt/current/public;
}

# Serve precompiled assets directly
location ~ ^/(assets)/ {
  gzip_static on;
  root /home/rails/lrt/current/public;
  expires max;
  # browser cache only
  add_header Cache-Control private;
}

Avoid Buffering

By default, nginx is configured for lower memory usage, so if a response is too large to fit in memory, nginx will write the excess data to disk to conserve memory. This is buffering and it’s a common issue for apps that serve API requests. To avoid buffering responses, I set proxy_buffers 4 256k, in this case, nginx is configured to hold up to 1MB of the response in memory. When combined with proxy_buffering off, nginx will send responses directly to the client, improving overall response times by skipping more unecessary disk I/O.

#########################################################
## Buffers
#########################################################
proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;
proxy_buffering off;

SSL/TLS

My TLS configuration follows Mozilla’s guidelines for a modern and secure setup, which also allows the site to score an “A” rating from SSL Labs. I’ve enabled OCSP stapling for a slight performance boost as well.

sl_protocols                    TLSv1.3;
ssl_session_cache               shared:SSL:10m;
ssl_session_timeout             10m;
ssl_certificate                 /etc/letsencrypt/live/httpscout.io/fullchain.pem;
ssl_certificate_key             /etc/letsencrypt/live/httpscout.io/privkey.pem;
ssl_session_tickets             off;
ssl_prefer_server_ciphers       off;
ssl_stapling                    on;
ssl_stapling_verify             on;

Logging

To make logs easier to parse and search, I’ve implemented JSON logging, which is particularly useful for troubleshooting and gathering statistics. This was something I picked up from velebit.ai.

# Modified version of JSON logging: https://www.velebit.ai/blog/nginx-json-logging/
log_format custom escape=json '{"source": "nginx", "time": "$time_iso8601", "resp_body_size": $body_bytes_sent, "host": "$http_host", "address": "$remote_addr", "request_length": $request_length, "method": "$request_method", "uri": "$request_uri", "status": $status, "user_agent": "$http_user_agent", "referrer" : "$http_referer", "resp_time": "$request_time", "upstream_addr": "$upstream_addr"}';

Final Thoughts

Update: Full Nginx config used in production. This is the same setup I use for HTTPScout.io. Managed via Ansible, with static file handling via try_files, asset routing, and rate limiting.

Anyways, I hope you find this config helpful!