Deployment de app
OpenFactory pode transformar repositório Git suportado em variant imutável de app, inicializar VM de replacement, fazer health-check e só então trocar rota do app depois que candidato estiver saudável. Serviços web e sites estáticos recebem URL em https://<slug>.apps.openfactory.tech quando caminho de ingress público está disponível.
Disponibilidade: pipeline de deployment e caminho de rota pública foram validados end to end. UI Apps e histórico de deployment não está pronta, jobs agendados são rejeitados e pass-through WebSocket/SSE ainda precisa teste de aceitação em produção dedicado. Trate URL retornada como utilizável só depois que status de deployment for
livee seu próprio pedido succeeder.
O que um deployment faz
- Resolve revisão Git exata com credenciais de origem conectadas da conta.
- Prepara origem sem copiar credenciais Git ou histórico
.gitpara imagem. - Empacota app via OBS quando selecionado e suportado, ou usa hook de build de imagem.
- Constrói e inicializa variant fresh específica do app.
- Escreve valores de ambiente de runtime após boot, inicia serviço e roda health check.
- Troca rota do gateway e remove VM anterior só depois que novo candidato estiver saudável.
VM live é artefato de deployment. OpenFactory não instala, constrói nem edita origem dentro dela.
Deploy de app registrado
Registre origem uma vez:
create_app(
name="my-shop",
git_url="https://github.com/example/my-shop",
branch="main",
deployment_type="web-service",
port=3000,
visibility="private"
)Depois enfileire deployment:
deploy_app(app_id="<app-id>")deploy_app é assíncrono por default. Guarde app_id, deploy_id e build_id retornados e faça poll:
get_app_deploy_status(app_id="<app-id>", deploy_id="<deploy-id>")Deployment continua se cliente MCP der timeout. Não envie deployment duplicado só porque wait terminou. Verifique deployment existente primeiro.
Sucesso e falha
Resposta de fila bem-sucedida não prova que app está live. Exija tudo:
- status de deployment é
live; - estágio health-check passou;
- URL retornada serve revisão esperada; e
- checagem autenticada succeede quando visibility é
private.
Em falha, registre stage, error, build_id e deploy_id com falha. Como cutover é health-gated, candidato com falha deve deixar rota saudável anterior no lugar.
Estratégia de build
use_obs=true exige caminho OBS saudável e suportado e falha fechado se indisponível. use_obs=false seleciona hook de build de imagem. Omitir argumento deixa serviço escolher OBS para projetos Node/static suportados e fallback para hook.
Só valores com prefixo público podem ser baked em variant. Segredos e outros valores de runtime pertencem ao ambiente criptografado de app e são aplicados após boot.
Testar app hospedado em outro lugar
Não precisa fazer deploy do app via OpenFactory para testá-lo. Qualquer URL alcançável da VM tester pode ser usada com cenário de app ou walk autônomo.
Limites atuais
- Serviços web e sites estáticos são suportados; jobs agendados não.
- UI de gerenciamento para histórico de app está pendente; status MCP é fonte da verdade.
- Disponibilidade de preview depende de gateway de app, ingress wildcard, DNS e VM candidata.
- Previews privados são owner-gated hoje; sharing de membro de organização não está implementado.
- Rollback de checkpoint ainda não migrou para modelo de deployment imutável atual. Veja Checkpoints e rollback.