Docker

Início rápido

A auto-hospedagem roda a partir do pacote de implantação — os arquivos compose, o Helm chart e o modelo de .env. Solicite-o em help@seeyu.ai e execute os comandos abaixo na raiz do pacote descompactado.

cat > .env << EOF
BETTER_AUTH_SECRET=$(openssl rand -hex 32)
ENCRYPTION_KEY=$(openssl rand -hex 32)
INTERNAL_API_SECRET=$(openssl rand -hex 32)
CRON_SECRET=$(openssl rand -hex 32)
EOF

docker compose -f docker-compose.prod.yml up -d

Abra http://localhost:3000

Configuração de produção

1. Configurar o ambiente

cat > .env << EOF
BETTER_AUTH_SECRET=$(openssl rand -hex 32)
ENCRYPTION_KEY=$(openssl rand -hex 32)
INTERNAL_API_SECRET=$(openssl rand -hex 32)
API_ENCRYPTION_KEY=$(openssl rand -hex 32)
CRON_SECRET=$(openssl rand -hex 32)

# Your public origin. BETTER_AUTH_URL is derived from this automatically.
NEXT_PUBLIC_APP_URL=https://studio.yourdomain.com

# Database credentials. DATABASE_URL is composed from these by the compose file.
POSTGRES_USER=postgres
POSTGRES_PASSWORD=$(openssl rand -hex 24)
POSTGRES_DB=studio
EOF

Não defina DATABASE_URL nem BETTER_AUTH_URL no .env — o docker-compose.prod.yml compõe as duas na definição do serviço, e um valor colocado aqui é ignorado. Altere POSTGRES_* e NEXT_PUBLIC_APP_URL no lugar disso.

Guarde a ENCRYPTION_KEY e a API_ENCRYPTION_KEY em algum lugar fora deste servidor. A ENCRYPTION_KEY criptografa as variáveis de ambiente do workspace e pessoais, as chaves de API de provedores armazenadas, as credenciais OAuth de MCP e os secrets de deploy e de chat; a API_ENCRYPTION_KEY criptografa as chaves de API do Studio geradas pelos usuários. Nenhuma das duas pode ser regerada — restaurar o banco de dados com uma chave diferente deixa os dados que ela protegia permanentemente ilegíveis.

O arquivo compose se recusa a iniciar se BETTER_AUTH_SECRET, ENCRYPTION_KEY ou INTERNAL_API_SECRET estiver faltando, em vez de subir com valores vazios. O CRON_SECRET é tratado com mais leveza: sem ele, o serviço cron imprime o que definir e encerra, deixando o resto da stack rodando — assim, atualizar a partir de um arquivo compose anterior ao agendador continua funcionando.

As imagens acompanham a latest, a menos que você as fixe. Para produção, veja Upgrades.

2. Iniciar os serviços

docker compose -f docker-compose.prod.yml up -d

Seis serviços sobem:

ServiçoPortaFinalidade
studio3000Aplicação principal (limite de 8 GB de memória)
realtime3002Servidor WebSocket (limite de 1 GB de memória)
db5432PostgreSQL 17 com pgvector
redisinternaPub/sub e cache compartilhado — não publicado no host
cron—Roda os jobs em segundo plano conforme o agendamento
migrations—Aplica as migrações de schema uma vez e encerra

Confirme que os cinco serviços de longa duração estão em pé e que o migrations encerrou sem erro (é um job de execução única, sem healthcheck):

docker compose -f docker-compose.prod.yml ps

3. Colocar atrás de TLS

O Caddy é a opção de menor esforço — ele obtém e renova certificados automaticamente.

studio.yourdomain.com {
    request_body {
        max_size 250MB
    }

    handle /socket.io/* {
        reverse_proxy localhost:3002
    }

    reverse_proxy localhost:3000 {
        flush_interval -1
    }

}

Três pontos dessa configuração são específicos do Studio e fáceis de errar: /socket.io precisa alcançar o serviço realtime na 3002, o flush_interval -1 impede que o Caddy acumule a saída transmitida do agente em um único bloco atrasado, e o max_size precisa ficar acima do limite de 220 MB do endpoint de chat.

Para nginx, Traefik ou um load balancer de nuvem — e para o timeout de websocket do GKE — veja Rede.

Ollama

# With GPU
docker compose -f docker-compose.ollama.yml --profile gpu --profile setup up -d

# CPU only
docker compose -f docker-compose.ollama.yml --profile cpu --profile setup up -d

Baixe modelos adicionais — o nome do serviço muda conforme o profile:

# GPU profile
docker compose -f docker-compose.ollama.yml exec ollama ollama pull llama3.2

# CPU profile
docker compose -f docker-compose.ollama.yml exec ollama-cpu ollama pull llama3.2

Ollama externo

Se o Ollama roda na sua máquina host (e não no Docker):

# macOS/Windows
OLLAMA_URL=http://host.docker.internal:11434 docker compose -f docker-compose.prod.yml up -d

# Linux - use your host IP
OLLAMA_URL=http://192.168.1.100:11434 docker compose -f docker-compose.prod.yml up -d

Dentro do Docker, localhost se refere ao contêiner, não ao seu host. Use host.docker.internal ou o IP do host.

Comandos

# Did migrations succeed?
docker compose -f docker-compose.prod.yml logs migrations

# Is the scheduler firing?
docker compose -f docker-compose.prod.yml logs -f cron

# Upgrade: bump STUDIO_VERSION in .env when pinned, then
bun run studio update

Common Questions

Sim. O serviço cron roda os mesmos jobs que o Helm chart agenda como CronJobs do Kubernetes, usando os agendamentos de docker/crontab. Ele precisa do CRON_SECRET — sem ele, o serviço imprime o que definir e encerra, e o resto da stack continua rodando.
O Redis dá suporte ao pub/sub do status ao vivo das tarefas do Chat e dos eventos de tabela, além de caches compartilhados. O pub/sub não tem fallback que funcione entre processos, então o status ao vivo não seria transmitido sem ele. A porta deliberadamente não é publicada, para não colidir com um Redis local.
Faça o backup com: docker compose -f docker-compose.prod.yml exec db pg_dump -U postgres studio > backup.sql. Restaure com: docker compose -f docker-compose.prod.yml exec -T db psql -U postgres studio < backup.sql. Os dados do banco ficam persistidos em um volume do Docker chamado postgres_data.
Sim. O docker-compose.prod.yml usa valores padrão de variáveis de ambiente: POSTGRES_USER (padrão: postgres), POSTGRES_PASSWORD (padrão: postgres), POSTGRES_DB (padrão: studio) e POSTGRES_PORT (padrão: 5432). Defina essas variáveis no seu arquivo .env para sobrescrevê-las.
ArquiteturaKubernetes