Flask

• Detectado pelo requirements.txt ou pyproject.toml que listam flask.
• Web: gunicorn na $PORT com app:app. Se seu app estiver em outro lugar, defina o start command para o seu module:callable (para uma app factory, "myapp:create_app()").
• Release: nenhum por padrão. Com Flask-Migrate, defina como flask db upgrade; com Alembic, alembic upgrade head. Uma linha release: no Procfile é usada quando presente.
• Banco de dados: psycopg → Postgres, com DATABASE_URL injetado.
• Workers e cron: o RQ é oferecido quando é uma dependência. Para Celery, adicione worker: celery -A myapp.celery worker ao seu Procfile ou adicione na aba Workers.

Workers são um segundo processo do mesmo app

O Flask não tem uma convenção própria de worker, então o Railyard simplesmente aplica a regra 12-factor direto: declare um segundo processo no seu Procfile e ele escala de forma independente do web.

web: gunicorn app:app --bind 0.0.0.0:$PORT
worker: rq worker --url $REDIS_URL

Ou adicione na aba Workers do app sem tocar no repositório, e escale qualquer um deles pela CLI:

railyard scale my-app worker=2

O RQ é oferecido automaticamente quando é uma dependência; o Celery não é detectado automaticamente para Flask — não existe uma convenção única de onde a app do Celery vive — então declare o comando dele você mesmo. Veja Workers e jobs agendados para cron: um comando agendado ali, ou um segundo processo worker rodando celery -A myapp.celery beat.

Configuração e secrets

DATABASE_URL é injetado assim que psycopg/psycopg2 é uma dependência, e REDIS_URL assim que um cliente Redis (redis, rq) é. Todo o resto — SECRET_KEY, FLASK_ENV, feature flags — é uma variável de ambiente comum em Variables, ou railyard env:set my-app KEY=VALUE pela CLI, de forma que a mesma imagem roda sem alterações de staging até produção: paridade dev/prod, não um branch em tempo de build. Aponte para um banco de dados ou Redis rodando como serviço próprio no canvas com ${{redis.RAILYARD_PRIVATE_URL}} — resolvido por ambiente. Veja Variáveis e secrets.

Fazendo o deploy

• A partir de um repositório: cole a URL do Git, ou escolha no seletor depois que o GitHub estiver conectado — o Railyard lê requirements.txt/pyproject.toml, preenche o gunicorn e a DATABASE_URL, e faz deploy a cada push.
• Pela CLI: railyard create my-app https://github.com/me/my-app --addons postgres,redis, ou railyard git:remote && git push railyard main dentro do repositório.
• Um clique só: adicione o botão de deploy ao seu README, ou publique no catálogo de templates para qualquer pessoa lançar com os addons e variáveis já preenchidos.