Quatro papéis
Viewer, deployer, admin, owner. Cada um inclui as permissões do papel abaixo dele. Admins podem exigir aprovação antes que o release de um deployer seja publicado.
Segurança
Como o Railyard é protegido.
Os controles de segurança que o Railyard tem hoje.
Sua infraestrutura
Seus apps e dados vivem nos seus servidores.
O Railyard não é dono das máquinas onde seus apps rodam. Elas são criadas na sua própria conta de cloud ou conectadas a partir de hardware que você já controla, e seus bancos de dados e backups também ficam lá. O limite de acesso é seu, incluindo a possibilidade de revogar o nosso. Se você sair, seus apps continuam rodando como containers comuns no seu servidor.
Um score de segurança para a sua equipe
Dez verificações, cada uma com uma correção.
O score de segurança roda dez verificações na equipe e liga cada uma que falha à sua correção.
- Adoção de dois fatores na equipe
- Admins inativos e tokens de API sem uso
- Servidores atualizados e suportados com o ActiveProtect ativo
- Portas abertas, certificados e backups verificados
- Stagings e previews privados
pessoas
Acesso e papéis.
O acesso é por equipe, e cada papel é um subconjunto estrito do que está acima dele.
Login em dois fatores
TOTP com códigos de backup de uso único. O score de segurança sinaliza todo membro que ainda não ativou.
Single sign-on e SCIM
Entre pelo seu provedor de identidade via OIDC ou SAML, casado com o domínio do seu e-mail e um papel padrão. O SCIM adiciona e remove membros para você.
Chaves SSH da equipe
Chaves adicionadas à equipe são instaladas nos servidores dela, e as chaves de um membro são removidas quando ele sai da equipe.
servidores
Hardening de servidores.
O agente do Railyard em cada servidor faz o trabalho de hardening de rotina que ninguém lembra de fazer.
ActiveProtect
Um IP que sonda três caminhos de scanner em um minuto, como /.env ou /wp-login.php, é banido no firewall por um dia. Força bruta por SSH também é banida. Seus próprios IPs podem ser marcados como confiáveis.
Atualizações de SO
Cada servidor reporta atualizações pendentes e de segurança, se precisa de reinício, e se o SO já passou do fim de vida. Aplique em um clique e mantenha as atualizações de segurança noturnas ativas.
Volumes de dados criptografados
Os dados de um banco de dados podem viver em um volume criptografado com LUKS2, para que uma imagem de disco copiada fique ilegível.
rede
Regras de rede.
As regras rodam no edge, no seu próprio servidor, antes de uma requisição chegar ao seu app.
Regras de IP e senhas
Listas de permissão ou bloqueio de endereços por app, e proteção por senha para stagings e previews.
Rate limits e bloqueio por país
Limites de requisição por path, e listas de países permitidos ou bloqueados, definidas em um formulário.
Bancos de dados ficam privados
Um banco de dados só é alcançado de fora por um proxy TCP que você ativa, limitado aos endereços em que você confia.
HTTPS automático
Certificados são emitidos e renovados para cada domínio, e você pode subir os seus próprios.
secrets
Secrets e backups.
Credenciais são criptografadas em repouso e entregues só onde são necessárias.
Criptografados em repouso
Variáveis de ambiente, secrets de build, tokens de provedores de cloud, senhas de registry e secrets de dois fatores são criptografados no banco de dados.
Nunca embutidos nas imagens
Secrets usados no build são passados durante o build, nunca gravados em uma camada da imagem.
Ocultos por padrão
Os valores das variáveis ficam ocultos na CLI e nas respostas da API até alguém pedir para revelar um deles.
Backups verificados
Um verificador restaura os backups, para que um backup inutilizável seja encontrado antes de você precisar dele.
tokens
Tokens e aprovações.
Credenciais de máquina têm escopo limitado, são revogáveis e nunca são compartilhadas entre servidores.
Tokens de API com escopo
Leitura ou leitura-escrita, com expiração opcional. Revogue um sem afetar os outros. Só um hash SHA-256 é armazenado.
Um token por servidor
O agente de cada servidor tem seu próprio token, para que um servidor comprometido não possa falar em nome de outro. Um agente novo não faz nada até um admin reivindicá-lo.
Aprovação humana para agentes
Quando um agente de IA pede para excluir um app ou remover uma variável via MCP, nada acontece até um admin aprovar.
Webhooks assinados
Webhooks enviados levam uma assinatura HMAC-SHA256, para que seu endpoint possa provar que a chamada veio do Railyard.
auditoria
Log de auditoria.
O log de atividade da equipe é a resposta para quem mudou o quê, e quando.
Toda mudança, atribuída
Deploys, rollbacks, mudanças de variáveis, mudanças de membros e aprovações, cada uma com a pessoa responsável.
Toda sessão de shell
Abrir um shell em um container em execução é registrado com quem abriu e o comando que foi iniciado.
Exportação em CSV
Exporte o log de atividade para seus próprios registros ou para um auditor.
Reportar uma vulnerabilidade
Envie um e-mail para security@railyard.run com detalhes suficientes para reproduzir o problema. Vamos confirmar o recebimento em até dois dias úteis e manter você informado até a resolução. Por favor, não teste contra a infraestrutura de outros clientes.
Veja também todas as funcionalidades e Railyard para agentes de código.
Faça o deploy do seu primeiro app em um servidor que é seu.
Conecte uma máquina com um host, um usuário e uma chave SSH, ou deixe a Railyard criar uma na sua conta de nuvem. Ela instala o resto e acompanha até a app entrar no ar.
Plano grátis, sem cartão, e 14 dias de Pro para cada equipe nova. Um preço fixo por equipe.