08. Como mostrar o mural de recados para o mundo?

Ver capítulo

Este capítulo é opcional. Foi testado num deploy de verdade em 2026-10-08, com Rails 8.1.4 e Ruby 4.0. As telas do Render mudam com frequência: antes do workshop, vale alguém da organização refazer o capítulo, do zero, com uma conta nova.

Perguntas para o “Pense antes”

“Onde o app roda hoje? E quando você fecha o codespace?” Leva à ideia de um computador ligado o tempo todo.
“Os seus recados de teste vão junto?” Leva à separação entre desenvolvimento e produção.
“Se qualquer pessoa pode abrir, o que pode dar errado?” Abre a conversa sobre segurança (veja abaixo).

Confusões comuns

A janelinha da palavra-chave. O usuário é sempre mural; a senha é a ACCESS_PASSWORD. É comum digitar a palavra-chave no campo do usuário. A janelinha é do navegador, então o texto aparece no idioma dele.
Esquecer o commit e o Sync Changes do passo 5. O Render só enxerga o que está no GitHub.
Clicar em Generate na RAILS_MASTER_KEY. O botão aparece ao lado do campo e parece o caminho fácil, mas cria uma chave que não abre as credentials do app. O deploy termina, e o app falha ao ligar.
Codespace sem o config/master.key. O master.key não vai para o GitHub, então um codespace criado de novo a partir do repositório (porque o antigo foi apagado, por exemplo) não tem a chave, e o credentials.yml.enc do repositório não abre com nenhuma outra. O bin/rails credentials:edit sozinho falha com Couldn't decrypt config/credentials.yml.enc. Perhaps you passed the wrong key?. A saída é criar um par novo: rm config/credentials.yml.enc e depois bin/rails credentials:edit, que cria um master.key e um credentials.yml.enc novos. Sem editor configurado, o comando mostra uma mensagem pedindo um (VISUAL="code --wait"), mas cria os dois arquivos mesmo assim. Depois, commit, Sync Changes e a chave nova colada no Render. O mural de recados não guarda nada nas credentials, então não se perde nada. Testado com Rails 8.1.4.
Deixar o Build Command que o Render sugere. O campo vem com bundle install; bundle exec rake assets:precompile; bundle exec rake assets:clean;. É preciso apagar e colar a receita do guia: sem o db:prepare, o app vai para o ar sem as tabelas. A receita do guia usa &&, e não ;: com o ;, o próximo comando roda mesmo se o anterior falhar.
Copiar a URL errada do banco de dados. É o Internal Database URL, não o External.
Regiões diferentes para o app e o banco de dados: o endereço interno não funciona entre regiões.
O app “dormindo”. Depois de 15 minutos sem acesso, a primeira visita demora cerca de um minuto. Não é erro.

Deploy ou deployment?

Contexto só para a mentoria. Não precisa levar para as participantes: o capítulo e o glossário só usam “deploy”, com a tradução “implantação”. Use só se alguém perguntar a diferença.

Se alguém perguntar: os dois existem. Em inglês, deploy é o verbo (“to deploy”) e deployment é o substantivo formal. No português de quem programa, “deploy” virou substantivo também (“fazer o deploy”, “o deploy falhou”), e deployment aparece mais em texto formal ou em nomes de ferramentas. O próprio Render usa Deploy nas telas (Deploys, Manual Deploy, Deploy web service). O guia usa só “deploy”, com a tradução “implantação” no “O que aconteceu?” e no glossário.

Decisões técnicas do capítulo

Contexto só para a mentoria. Não precisa levar para as participantes: o capítulo já explica o que elas precisam (por que o PostgreSQL e o que cada comando da receita faz). Aqui estão os motivos das escolhas de quem escreveu o guia, para responder perguntas ou para refazer o capítulo se o Render mudar.

PostgreSQL em produção, SQLite em desenvolvimento. No plano gratuito, o Render não tem disco permanente: um arquivo SQLite seria apagado a cada deploy ou reinício. O PostgreSQL gratuito dura 30 dias, o que basta para o workshop. O database.yml não muda: o DATABASE_URL substitui a configuração do banco principal em produção. Testado localmente com Rails 8.1.4 e PostgreSQL 17.
O cache, a fila e o cable continuam em SQLite em produção (as bases cache, queue e cable do Rails 8). Como o app não usa cache, jobs nem Turbo Streams, não tem problema se esses arquivos forem apagados.
A receita no campo Build Command, e não num bin/render-build.sh. A documentação do Render para Rails usa um arquivo bin/render-build.sh, mas não existe gerador para ele: seria criar o arquivo à mão e rodar o chmod +x, com o risco de um Permission denied no deploy. Com o campo, são menos passos. A desvantagem é que a receita fica no painel do Render, e não no repositório.
bin/rails server no Start Command. O Render sugere bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}. Ele também funciona: o -e development só vale quando a variável RACK_ENV não existe, e o Rails dá preferência ao RAILS_ENV, que o Render já define como production. O guia troca por bin/rails server porque é o comando que a participante já conhece, e porque ele usa o config/puma.rb do app e a porta da variável PORT, que o Render define.
RAILS_MASTER_KEY, como o Render sugere. É o padrão do Rails para produção (o Dockerfile e o Kamal do app também usam). Existe outro caminho, uma SECRET_KEY_BASE gerada pelo Generate do Render, mas o guia segue a sugestão do Render para mexer no mínimo. Não use o Generate na RAILS_MASTER_KEY: uma chave aleatória não abre o config/credentials.yml.enc, e o app falha ao ligar.
db:prepare, e não db:migrate, na receita. O db:prepare cria as tabelas dessas bases a partir dos arquivos *_schema.rb, e o db:migrate não.
A gem pg em todos os ambientes. Desde a versão 1.6, a gem pg tem versões pré-compiladas para Linux, então o bundle add pg funciona no Codespaces sem instalar nada no sistema.
Ruby 4.0 no Render. O Render lê o .ruby-version do app e instala a versão sozinho. No teste, o log mostrou Using Ruby version 4.0.6 via /opt/render/project/src/.ruby-version, seguido de Installing Ruby version 4.0.6....

Segurança

Contexto só para a mentoria. Não precisa levar para as participantes: o capítulo não tem uma parte sobre segurança, só os cuidados práticos (a palavra-chave e os segredos, que ficam no Render). Esta tabela é um roteiro para a conversa, se ela surgir.

O app no ar é público: qualquer pessoa com o endereço consegue abrir. Vale conversar sobre isso, sem assustar. O que o guia já cobre e o que fica de fora:

Tema	Situação	O que fazer
Segredos (`config/master.key` e `DATABASE_URL`)	O guia manda colar só no Render. O `master.key` já fica fora do Git pelo `.gitignore` do Rails.	Confira que a participante não colou a chave em nenhum outro lugar (chat, IA, print, commit). Se vazar, apague e recrie o banco de dados e gere uma chave nova (`bin/rails credentials:edit` com outra chave).
Robôs e curiosos	O passo 4 protege o app inteiro com uma palavra-chave (`http_basic_authenticate_with`, usuário `mural`, senha na variável `ACCESS_PASSWORD` do Render). Sem a variável, como no codespace, a proteção fica desligada.	Lembre que a palavra-chave é compartilhada: não pode ser uma senha pessoal. O `/up` (verificação de saúde do Render) continua aberto, porque não passa pelo `ApplicationController`.
Quem tem a palavra-chave pode postar, corrigir e apagar	Decisão do plano do capítulo 00: aceito para um mural de recados de workshop.	Sugira compartilhar o endereço e a palavra-chave só com o pessoal do workshop. Contas de usuária ficam em “Como avançar com o projeto”, nos desafios extras.
Conteúdo ofensivo ou spam	A palavra-chave segura os robôs, mas não há moderação nem limite de envios para quem tem a palavra.	Se acontecer, a própria participante apaga pelo botão Apagar. Ir além: o Rails 8 tem `rate_limit` no controller, por exemplo `rate_limit to: 10, within: 1.minute, only: :create`.
Dados pessoais	Os recados ficam públicos.	Oriente a não postar e-mail, telefone, endereço nem sobrenome completo de ninguém nos recados.
Código malicioso nos recados (como `<script>`)	Protegido: o `<%= %>` do ERB escapa o HTML, e o texto aparece como texto.	Nada. Se alguém testar, é uma boa demonstração de por que o Rails escapa o conteúdo por padrão.
Proteção de formulários (CSRF)	O `forgery_protection_origin_check = false` do capítulo 04 está só no `development.rb`. Em produção, a proteção está completa.	Nada.
HTTPS	O Render serve o app com HTTPS.	Nada.
Acesso do Render ao GitHub	O Render pede permissão para ler repositórios.	Sugira dar acesso só ao repositório do mural de recados (Only select repositories).
Dados apagados depois de 30 dias	O banco de dados gratuito expira.	Avise a participante, para não estranhar quando os recados sumirem.

Se o tempo apertar

O capítulo é opcional, e a página dele já diz que pode ser feito em casa. Se sobrar pouco tempo no dia, o mínimo é ver o mural de recados no ar, que são os passos 1 a 8. O passo 9 (mudar o título e ver o deploy automático) e o “O que aconteceu?” ficam para casa.

Se nem isso couber, há um ponto de parada seguro: depois do passo 5. Nesse ponto, a conta e o banco de dados já existem no Render, e o app está preparado e enviado ao GitHub (o pg, a palavra-chave e o commit). Em casa, a participante recomeça no passo 6, e nada fica pela metade.

Duas ideias que ajudam:

A conta no Render (passo 1) pode ser criada antes, por exemplo no intervalo, para ganhar tempo.
Uma demonstração também vale: se poucas pessoas chegarem ao capítulo, uma delas faz os passos na tela grande, e as outras acompanham e repetem em casa.

Próximas notas

09. Terminei! E agora?