activestorage-uploads

Active Storage Uploads

File uploads done right in Rails 8. AI agents generate the simplest possible has_one_attached :avatar and call it a day — missing direct uploads (so the Rails server proxies every byte), variant generation (computed in the request thread), and pre-signed URL safety. This skill closes those gaps.

Why this matters

File uploads are an attack surface and a performance liability. The naïve "user posts the file, Rails saves it" pattern blocks request workers for the duration of the upload, eats RAM on multi-MB files, and gives attackers an easy way to upload malware or oversized payloads. Direct upload + signed URLs + variant generation in jobs fixes all three.

The opinion

Direct uploads to S3/GCS (Rails server never sees the byte payload). image_processing + libvips for variants (NOT imagemagick). Variants generated in background jobs, never in the request. Pre-signed URLs with short TTLs (5–15 min) for downloads. Private buckets by default. Validate content-type + size on the model. Never accept user-provided filenames as URLs.

Counter-positions:

• CarrierWave / Shrine — predate Active Storage. Still legitimate; Shrine especially has features Active Storage lacks (multi-step processing, plugins). Default to Active Storage; reach for Shrine if you need its specific features.
• Cloudinary / Imgix — managed image CDNs that handle variants for you. Worth it for image-heavy apps; over-investment for an avatar field.

Core patterns

Pattern 1: Direct upload to S3 (skip the Rails server)

Before (AI default — every byte through Rails):

class User < ApplicationRecord
  has_one_attached :avatar
end

<%= form.file_field :avatar %>

User uploads 50MB → Rails server holds the whole thing in memory → forwards to S3. A worker is blocked for the upload duration. Memory spikes. Concurrent uploads OOM.

After (direct upload):

<%= form.file_field :avatar, direct_upload: true %>

Plus the JS: