Você guarda as chaves. A TradingHost executa o código.
A TradingHost é o ambiente de execução para estratégias de trading automatizadas, não o cofre para credenciais de corretoras ou exchanges.
Mantenha chaves de API, segredos de assinatura, senhas e tokens de provedores de dados no cofre de segredos em que você já confia. A TradingHost oferece à sua estratégia um caminho de execução para ler os valores necessários sem embutir arquivos .env em deploys, codificar credenciais diretamente no GitHub ou colar credenciais de corretoras no painel da TradingHost.
Sem arquivos .env em imagens. Sem chaves de corretoras codificadas no código. Sem credenciais de exchanges coladas no painel.
Postura de segredos
- Sem custódia de segredos
- Cofres de segredos externos
- Variáveis de ambiente em tempo de execução
- Deploys nativos do GitHub
- Rotação controlada pelo cliente
- Trilha de auditoria controlada pelo cliente
- As credenciais de corretoras e exchanges continuam sendo suas
Seção 01 · Posicionamento
A TradingHost é o ambiente de execução, não o cofre.
A TradingHost executa o código da sua estratégia dentro de ambientes de execução gerenciados na nuvem. Suas chaves de corretoras, chaves de API de exchanges, segredos de webhook, chaves de assinatura e tokens de dados de terceiros devem permanecer no seu próprio cofre de segredos.
O cofre de segredos continua sendo a única fonte da verdade. Seu ambiente de execução recebe os valores necessários quando a estratégia é iniciada. Sua estratégia lê esses valores usando variáveis de ambiente ou um padrão documentado de busca em tempo de execução.
A TradingHost fornece o fluxo de deploy, o ambiente de execução, os logs, as verificações de integridade (health checks), os controles de recursos, a seleção de região e a interface de controle do MCP para a estratégia. Ela não precisa se tornar o local onde suas credenciais de trading residem.
Isso mantém o limite de segurança simples:
O resultado é um modelo de produção mais limpo para trading automatizado: seu código roda na TradingHost, enquanto a custódia das credenciais permanece com você.
Seção 02 · O que é considerado um segredo?
Qualquer valor privado que sua estratégia precise para rodar.
Um segredo é qualquer valor que, se vazado, concede acesso a uma conta, serviço, conexão ou fluxo de trabalho de trading.
Exemplos comuns incluem:
- Chaves de API de corretoras
- Chaves de API de exchanges
- Segredos de API
- Chaves de assinatura
- Passphrases
- Segredos de webhook
- Tokens de dados de mercado
- Senhas de banco de dados
- Credenciais de endpoint privado
- Segredos de cliente OAuth
- Tokens de serviços internos
Uma credencial é um tipo específico de segredo usado para autenticação em uma corretora, exchange, provedor de dados, banco de dados ou serviço de terceiros.
A maioria das credenciais de trading não consiste em apenas um único valor. Elas podem incluir uma chave, um segredo, uma passphrase, um ID de conta, um ID de subconta, um nome de ambiente ou um escopo de permissão.
O TradingHost trata esses elementos como inputs de runtime, não como dados do produto.
Seção 03 · Como os segredos chegam ao runtime
Do seu gerenciador de segredos para a sua estratégia em execução.
O fluxo do runtime é intencionalmente familiar. Ele funciona como o deploy de aplicações em produção, pipelines de CI e cargas de trabalho modernas em nuvem.
Passo 1
Armazene a credencial
Mantenha a credencial da corretora ou exchange no gerenciador de segredos que você já utiliza. Pode ser o GitHub Actions secrets, HashiCorp Vault, AWS Secrets Manager, Doppler, 1Password Secrets Automation, Infisical, Bitwarden Secrets Manager ou outro cofre compatível. Seu gerenciador de segredos continua sendo a única fonte da verdade.
Passo 2
Faça o deploy do runtime
Seu deploy gerenciado via GitHub inicia o runtime do TradingHost. O runtime recebe os valores que sua estratégia precisa por meio do padrão de entrega de segredos configurado. Para a maioria das estratégias, esses valores são expostos como variáveis de ambiente na inicialização.
Passo 3
Inicie a estratégia
Sua estratégia lê as variáveis, conecta-se à corretora, exchange, provedor de dados de mercado ou serviço interno e começa a rodar dentro do runtime do TradingHost. A relação de trading permanece diretamente entre sua estratégia e a plataforma de execução.
Caminho do runtime
Seu
Gerenciador de segredos
GitHub Actions, Vault, AWS Secrets Manager, Doppler, 1Password, Infisical ou Bitwarden. A fonte da verdade para a credencial.
TradingHost
Runtime
O deploy via GitHub inicia o runtime. O padrão de entrega configurado expõe o valor para o processo da estratégia.
Seu
Corretora, exchange ou provedor de dados
Sua estratégia se conecta, autentica e opera. A relação permanece entre sua estratégia e a plataforma de execução.
Seção 04 · Gerenciadores de segredos compatíveis
Use um gerenciador de segredos em que você já confia.
O TradingHost foi projetado para padrões de fontes externas de segredos. Você não precisa mover todas as credenciais de corretoras ou exchanges para um cofre de propriedade do TradingHost apenas para rodar uma estratégia.
Os provedores abaixo são os padrões de gerenciamento de segredos documentados prioritariamente pelo TradingHost.
O TradingHost não força você a abandonar sua estrutura de segurança atual. Se você já possui um gerenciador de segredos, modelo de acesso, frequência de rotação e trilha de auditoria estabelecidos, o objetivo é continuar usando-os.
Seção 05 · Visão geral
O modelo de segredos explicado de forma direta.
A distinção importante é simples:
A TradingHost executa o processo. Seu secret store gerencia as credenciais.
Seção 06 · O que a TradingHost não precisa
Sem dispersão de credenciais para rodar uma estratégia.
Um ambiente de execução (runtime) de trading não deve exigir cópias soltas de credenciais confidenciais espalhadas por notebooks, chamados, capturas de tela, mensagens de chat, ferramentas de suporte, repositórios e arquivos .env não gerenciados.
Com a TradingHost, você não precisará:
- Fazer hardcode de chaves de corretoras em um repositório
- Embutir arquivos .env em imagens de container
- Colar credenciais de exchanges em um painel genérico
- Enviar chaves de API para a equipe de suporte
- Armazenar segredos de produção em planilhas
- Acessar um servidor via SSH apenas para editar variáveis de ambiente
- Compartilhar chaves por chat ou e-mail
- Copiar credenciais manualmente entre ambientes
- Manter chaves antigas ativas por perder o controle de onde estão sendo usadas
O modelo mais limpo é manter os segredos em um único local seguro e permitir que o runtime receba apenas o que a estratégia precisa.
Seção 07 · O que continua sendo seu
A governança das credenciais permanece sob seu controle.
A TradingHost fornece o runtime. Você mantém o controle sobre as decisões de credenciais confidenciais.
Você decide:
- Qual secret store utilizar
- Qual estratégia pode acessar cada credencial
- A qual conta de corretora ou exchange uma chave pertence
- Se uma chave pode operar, consultar saldos, consultar posições ou realizar saques
- Com que frequência as credenciais são rotacionadas
- Quem pode visualizar ou modificar segredos de produção
- Como a revogação é tratada
- Onde os registros de auditoria são revisados
- Quais ambientes podem acessar credenciais de produção
- Se chaves separadas são usadas para desenvolvimento, homologação e produção
Isso é fundamental para a infraestrutura de trading porque as permissões de API podem ser financeiramente sensíveis. Uma chave de corretora ou exchange pode conceder acesso a saldos, posições abertas, envio de ordens, histórico da conta ou funções de saque.
O TradingHost não deve ser o motivo pelo qual essas permissões se tornem mais difíceis de governar.
Seção 08 · Comportamento do runtime
Sua estratégia lê segredos como uma aplicação de produção.
Uma estratégia implantada no TradingHost deve tratar segredos como configuração de runtime.
Por exemplo:
Estratégia de cripto
- EXCHANGE_NAME
- EXCHANGE_API_KEY
- EXCHANGE_API_SECRET
- EXCHANGE_API_PASSPHRASE
- TRADING_MODE
Estratégia conectada a corretora
- BROKER_NAME
- BROKER_ACCOUNT_ID
- BROKER_API_KEY
- BROKER_API_SECRET
- BROKER_ENVIRONMENT
Estratégia de dados de mercado
- DATA_PROVIDER
- DATA_API_KEY
- DATA_REGION
- DATA_FEED
Os nomes exatos das variáveis são definidos pelo seu projeto, framework, conector ou fluxo de trabalho de implantação.
O TradingHost não precisa entender o valor privado em si. Ele só precisa fornecer ao processo em execução uma maneira de acessar a configuração esperada.
Seção 09 · Logs e observabilidade
Segredos nunca devem ser impressos.
O TradingHost fornece logs de runtime e visibilidade de integridade para que você possa ver se uma estratégia está em execução, falhando, reiniciando, conectando ou emitindo erros.
Esses logs são úteis para operações de produção, mas não são um local seguro para segredos.
Sua estratégia nunca deve imprimir:
- Chaves de API
- Segredos de API
- Payloads de assinatura
- Passphrases
- Cabeçalhos de autenticação
- Tokens Bearer
- Segredos de webhook
- Strings de conexão completas
- Dumps brutos de variáveis de ambiente
- Tokens de sessão de corretora
- Respostas de autenticação de exchange
O TradingHost exibe os logs emitidos pelo seu processo. Se uma estratégia gravar um segredo no stdout, stderr, stack traces, saídas de depuração ou payloads de erro, esse valor poderá ficar visível nos logs de runtime.
O padrão mais seguro é registrar o estado da conexão, não os valores das credenciais.
Bom
- Conectado à conta spot da Binance.
Ruim
- Conectado à Binance usando a chave de API abc123...
Seção 10 · Limite de segurança
O limite, de forma direta.
O TradingHost não deve ser tratado como o sistema de registro para credenciais de corretoras ou exchanges.
Suas credenciais devem residir no seu próprio cofre de segredos, governadas por seus próprios controles de acesso, políticas de rotação e processos de auditoria.
O TradingHost não deve exigir que segredos sejam enviados ao GitHub, embutidos em imagens de implantação, adicionados a arquivos .env dentro do container ou compartilhados com a equipe de suporte.
O TradingHost fornece a camada de runtime em torno da estratégia. Sua estratégia usa o padrão configurado de entrega no runtime para acessar os valores necessários. Sua corretora, exchange, provedor de dados ou serviço interno continua sendo o sistema que autentica a credencial e aplica as permissões no nível da conta.
Essa separação é o ponto principal.
O TradingHost executa o código.
Você governa as chaves.
FAQ
Perguntas frequentes
O TradingHost foi projetado para que o seu gerenciador de segredos (secret store) continue sendo a fonte da verdade para as credenciais de brokers e exchanges. O runtime recebe os valores que sua estratégia precisa por meio de um padrão configurado de entrega de segredos, em vez de exigir que você insira chaves diretamente no código ou inclua arquivos .env nas imagens.
Não. Chaves de brokers, chaves de API de exchanges, passphrases, chaves de assinatura e tokens de provedores de dados nunca devem ser incluídos em um repositório. Use o GitHub Actions secrets, um gerenciador de segredos externo ou outro padrão de segredos em runtime documentado.
A imagem do seu deployment não deve incluir um arquivo .env com credenciais ativas. Os segredos devem ser fornecidos em runtime, e não empacotados no código-fonte ou na imagem.
A maioria das estratégias lê os segredos a partir de variáveis de ambiente na inicialização. Algumas configurações usam um padrão de busca (fetch) em runtime a partir do Vault, AWS Secrets Manager, Doppler, 1Password, Infisical, Bitwarden ou outro gerenciador compatível, dependendo de como o fluxo de trabalho de deployment está configurado.
A rotação ocorre no seu gerenciador de segredos ou diretamente no broker, exchange ou provedor de dados. Assim que uma credencial for rotacionada, reinicie ou faça o redeploy do runtime afetado para que a estratégia receba o novo valor.
Revogue a credencial no sistema que a emitiu. Para chaves de trading, isso geralmente significa o broker, exchange, provedor de dados ou serviço interno. Você também deve remover ou substituir o valor no seu gerenciador de segredos.
Apenas se sua estratégia os exibir no console. O TradingHost exibe os logs emitidos pelo seu processo, portanto, as estratégias nunca devem imprimir credenciais, dumps de ambiente, cabeçalhos de autenticação, tokens, passphrases ou strings de conexão brutas.
O TradingHost não possui uma interface voltada para a equipe ler credenciais de brokers ou exchanges dos clientes. Seu próprio gerenciador de segredos deve continuar sendo o local onde o acesso aos valores das credenciais é controlado e auditado.
Sim. O TradingHost foi projetado com base em padrões de fontes externas de segredos. Se o seu gerenciador de segredos puder expor valores por meio de variáveis de ambiente ou de um padrão de busca (fetch) em runtime documentado, ele geralmente se adaptará ao modelo de deployment do TradingHost.
O TradingHost documenta padrões para GitHub Actions secrets, HashiCorp Vault, AWS Secrets Manager, Doppler, 1Password Secrets Automation, Infisical e Bitwarden Secrets Manager.
Traga seu próprio gerenciador de segredos. Faça o deploy com o GitHub.
Conecte o GitHub, configure seu runtime e aponte sua estratégia para o gerenciador de segredos em que você já confia.
O TradingHost executa o código.
Você fica com as chaves.