📁

Rails Directory Structure

Roles and conventions for each project folder

When you create a Rails project with rails new, a standard directory structure is generated.

app/ — Core application code

app/models/ — ActiveRecord models (data + business logic)
app/controllers/ — Request-handling controllers
app/views/ — ERB templates (HTML)
app/helpers/ — View helper methods
app/mailers/ — Email delivery
app/jobs/ — Background jobs
app/channels/ — Action Cable (WebSocket)
app/javascript/ — JavaScript files
app/assets/ — Images, fonts, and other static files

config/ — Configuration files

routes.rb — URL → Controller mapping
database.yml — DB connection info
credentials.yml.enc — Encrypted secrets
initializers/ — Settings executed at Rails startup

db/ — Database

migrate/ — Migration files (schema change history)
schema.rb — Current schema snapshot
seeds.rb — Seed data

spec/test/ — Test code
lib/ — Custom libraries
public/ — Static files (error pages, etc.)

Key Points

1

app/models/ — Data models and business logic (User, Post, Comment, etc.)

2

app/controllers/ — HTTP request handling (PostsController, UsersController, etc.)

3

app/views/ — HTML templates (ERB files, controller_name/action_name.html.erb)

4

config/routes.rb — URL routing rules

5

db/migrate/ — Database schema change history (timestamp_description.rb)

6

spec/ or test/ — Test code (model specs, controller specs, etc.)

Pros

✓ Clear separation by role
✓ Predictable code locations
✓ rails generate auto-creates files in correct locations
✓ Consistent structure across Rails projects

Cons

✗ Overwhelming number of directories at first
✗ app/models/ etc. can bloat in large projects
✗ Paths get long as namespace structure grows complex

Use Cases

Starting a new Rails project Determining file locations in team projects Understanding file roles during code review CI/CD pipeline configuration

Related

Convention over Configuration

Rails' core philosophy — convention trumps configuration

← 📏 Convention over Configuration 🧅 Rack & Middleware →