Zero-Config Database Migrations on Deploy

The forgotten migration problem

Every Rails, Django, and Phoenix developer has been here: you push a feature, the deploy succeeds, and the app crashes with a missing column error. You forgot to run rake db:migrate. Or someone else did. Or the CI step that was supposed to run it silently failed.

This is the kind of bug that shouldn't exist in 2026, but somehow still does on most platforms.

FluxNow turns the classic “forgot to run migrations” outage into a non-event by auto-detecting and reliably running your release/migration command before every deploy, using Kubernetes init containers.

Key ideas:

• Automatic detection
• Scans your repo on onboarding for framework signals:
• Gemfile → Ruby / Rails
• manage.py → Python / Django
• mix.exs → Elixir / Phoenix
• prisma/schema.prisma → Prisma
• Procfile → Heroku-style release directive
• If a Procfile exists and has release: ..., FluxNow uses that command.
• If not, it falls back to framework defaults:
• Rails (config/application.rb) → bundle exec rake db:migrate
• Django (manage.py) → python manage.py migrate
• Phoenix (mix.exs) → mix ecto.migrate
• Prisma (prisma/schema.prisma) → npx prisma migrate deploy
• Config generation
• Detected command is written into fluxnow.yaml:

version: v1
kind: Service
name: my-app

# FluxNow detected Rails — release command auto-generated.
# Edit this to override, or add a release: line to your Procfile.
release: bundle exec rake db:migrate