Conta e Bootstrap
Há duas maneiras de começar com o Nexo SaaS.
A. Seed do banco de dados (primeira inicialização típica do Docker)
docker compose -f deploy/docker-compose.yml exec app php artisan db:seed --force
Cria (entre outras coisas):
- Administrador da plataforma [email protected] / senha com e-mail já verificado
- Teste do cliente [email protected]
- Catálogo de exemplo (pacotes, módulos, complementos)
- Configuração padrão do host + plataforma
Adequado para avaliação local. Altere senhas e e-mails antes de qualquer ambiente compartilhado.
B. Registro de banco de dados vazio (estilo produção)
- Abrir /register.
- Crie a primeira conta.
- Se ainda não existir um administrador da plataforma, esse usuário é promovido automaticamente a administrador da plataforma e recebe uma organização pessoal.
- O aplicativo redireciona para a verificação de e-mail (/verify-email).
Até que o e-mail seja verificado, o usuário não pode usar o painel ou a área de administração (middleware de autenticação + verificação).
Verificação de e-mail sem SMTP
O SMTP é necessário para o e-mail de produção (links de verificação, faturas, notificações de implantação). Na primeira instalação, muitas vezes você configura o SMTP após criar a conta de administrador.
Artesão: verifique um usuário por e-mail
# Docker
docker compose -f deploy/docker-compose.yml exec app \
php artisan platform:verify-user [email protected]
# Bare metal / VPS app directory
php artisan platform:verify-user [email protected]
Comportamento:
- Define email_verified_at como agora (idempotente se já estiver verificado).
- Escreve um log de auditoria (auth.email_verified, via artisan).
- Opcional: --unverify limpa a verificação (apenas para testes).
Em seguida, faça login e continue para o painel.
Aviso: Qualquer pessoa com acesso ao shell ao contêiner da aplicação pode verificar qualquer e-mail. Restrinja o acesso SSH/deploy como se fosse qualquer outro segredo de produção.
Depois que o SMTP é configurado
Prefira e-mails de verificação normais (reenviar na tela de verificação). Mantenha platform:verify-user como inicialização de emergência/recuperação de suporte.
Saiba mais sobre a configuração do SMTP.
Privilégios de administrador da plataforma
| Capability | Platform admin | Org member |
|---|---|---|
| Admin → Settings, Catalog, Refunds, Users | Yes | No |
| Horizon (queue UI) | Yes (with 2FA policy) | No |
| Manage any installation | Yes (admin tools) | Own org only |
| Checkout / org billing | Via membership | Yes (role-dependent) |
Promover ou rebaixar
php artisan platform:promote-admin [email protected]
php artisan platform:promote-admin [email protected] --demote
- Não é possível rebaixar o último administrador da plataforma.
- Fora do local, os administradores da plataforma devem habilitar 2FA antes que /dashboard/admin funcione.
Política de 2FA
| Audience | Policy |
|---|---|
| Platform admins (non-local) | Required for admin routes |
| Customers | Optional when Admin → Settings → General → Two-factor available is enabled |
Contas de clientes e organizações
Ao se registrar (qualquer usuário):
- A linha do usuário foi criada.
- Uma organização pessoal é criada com o usuário como proprietário.
- Os limites de assentos/instalações vêm dos padrões em Admin → Settings → Deployments (default_max_seats, default_max_installations).
As organizações da equipe, convites e funções são abordados em 05 — Cobrança, orgs e reembolsos.
Sequência de inicialização recomendada para produção
- Implantar stack
- Ou faça a semente e depois altere as credenciais de administrador, ou registre o e-mail real do operador em um banco de dados vazio.
- plataforma:verificar usuário operador@… se o e-mail não estiver pronto.
- Ative a autenticação de dois fatores (2FA) para o administrador.
- Configure o SMTP em Admin → Configurações
- Configurar pagamentos, domínio, GitHub, S3
- php artisan platform:launch-check.
- Opcionalmente, plataforma:promote-admin, operadores adicionais; verifique cada e-mail.