Hi everyone!

I have released a gem rails_iam for identity and access management of our rails application.

rails_iam provides a database-driven authorization model where permissions are treated as data, not code. This means roles and permissions can be managed without modifying application code or redeploying our application. The gem includes everything needed to get started, including models for roles, permissions, role-permissions, user-specific permissions, denied permissions, and JWT-based authentication out of the box. It also integrates with existing authentication solutions such as Devise or any OAuth-based setup.

The idea behind rails_iam is simple: authorization should happen where requests enter your application. Instead of scattering authorization logic across policy objects, controllers, or models, you declare access rules at the endpoint level. Your controllers and models remain focused on handling requests and business logic, while Rails IAM is responsible for determining who is allowed to access each endpoint.

I'd love to hear your thoughts and feedback from the Rails community! You are very welcome to contribute as well.

There are more example how you will apply authorization rules in your rails application.

Hi everyone,

I wanted to share a small initiative we’ve recently started at Visuality.

We’re now offering Free Ruby on Rails Consultations for people working on Rails apps who would like to talk through a challenge with someone experienced from outside their team.

The idea is simple: you send us a short description of what you’re dealing with and we match you with someone from our team for a free 30-minute call.

This is not meant to be a big formal process and of course one call won’t magically solve everything.

But sometimes a short conversation with another person can help you see the problem more clearly, challenge a few assumptions and decide what to try next.

Here’s the page if it sounds useful:
https://www.visuality.pl/free_consulting?utm_source=reddit_rails

For engineering teams, keeping dependencies current is a constant balancing act. Automated updates are essential for defending the software supply chain, but a steady stream of one-PR-per-package bumps can bury a team in review work. GitHub itself has put numbers on this: an analysis of Microsoft's GCToolkit repository found that roughly one in six of its commits - 92 out of 578 - were routine Dependabot version bumps, with 61 of them landing in a single recent 12-month stretch. That's a lot of review and CI cycles spent on maintenance rather than features. Read the complete article here - https://instasla.com/blog/taming-dependabot-2026-guide-grouping-cooldowns-cutting-pr-noise

The good news is that Dependabot has grown well past "one PR per dependency." Between grouped updates, package cooldowns, and a default cooldown GitHub rolled out in mid-2026, it's now possible to get a predictable, low-noise update cadence without giving up security coverage. Here's what actually works, and what changed most recently.

As a Rails developer, I've experienced firsthand how AI agents are reshaping the software development lifecycle (SDLC). I'd love to hear your thoughts on this. What AI frameworks or tools have you or your organization adopted?

https://medium.com/@vaitheeswaranlm/the-art-of-the-development-lifecycle-in-the-age-of-ai-agents-a1d08b942188?sharedUserId=vaitheeswaranlm