Phoenix e Elixir

• Bancos de dados a partir do mix.exs: ecto_sql/postgrex → Postgres, ecto_ch/ch → ClickHouse, redix → Redis.
• Migrations: mix ecto.migrate. Releases compilados não têm mix em tempo de execução, então o Railyard encontra o release onde a imagem o coloca e roda seu migrator (bin/migrate, se existir, ou então bin/<app> eval). O mix phx.server se torna bin/<app> start da mesma forma.
• Variáveis lidas em config/runtime.exs (BASE_URL, HTTP_PORT, LISTEN_IP, DATABASE_URL, CLICKHOUSE_DATABASE_URL…) são ligadas automaticamente; SECRET_KEY_BASE é gerado.
• MIX_ENV=prod e PHX_SERVER=true são definidos.

Jobs em segundo plano geralmente não precisam de um segundo processo

A maioria dos apps Elixir roda jobs com Oban — uma fila baseada em Postgres iniciada na mesma árvore de supervisão do endpoint web, então já está rodando no momento em que o web sobe, sem nenhum worker separado para declarar ou escalar. Isso ainda é o modelo 12-factor: o executor de jobs é só mais um dos papéis que o seu release OTP único já desempenha, não um segundo deployable para manter sincronizado com o primeiro.

Se você quiser um node worker dedicado — separando o processamento de jobs em um processo próprio para que uma fila lenta não sufoque as requisições web — declare isso em um Procfile e faça seu release ler uma flag ou variável de ambiente para pular a inicialização do endpoint:

web: bin/my_app start
worker: bin/my_app eval "MyApp.Release.worker()"

Adicione ou edite processos na aba Workers do app sem mudar o repositório, e escale qualquer um deles pela CLI:

railyard scale my-app worker=2

Configuração e secrets

Tudo que config/runtime.exs lê com System.get_env/2 é uma variável comum: defina em Variables, ou railyard env:set my-app KEY=VALUE pela CLI, e o mesmo release compilado roda sem alterações de staging até produção — paridade dev/prod, não um build diferente por ambiente. Aponte para um banco de dados, ClickHouse 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ê o mix.exs, preenche o ecto.migrate, o banco de dados provisionado e o SECRET_KEY_BASE, e faz deploy a cada push.
• Pela CLI: railyard create my-app https://github.com/me/my-app --addons postgres, 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.