Read time … min

You hold the keys. TradingHost runs the code.

TradingHost is the runtime for automated trading strategies, not the vault for broker or exchange credentials.

Keep API keys, signing secrets, passphrases and data-provider tokens in the secret store you already trust. TradingHost gives your strategy a runtime path to read the values it needs without baking .env files into deployments, hardcoding credentials into GitHub, or pasting broker credentials into the TradingHost dashboard.

No .env files in images. No hardcoded broker keys. No pasted exchange credentials in the dashboard.

Secrets posture

  • No secret custody
  • External secret stores
  • Runtime environment variables
  • GitHub-native deploys
  • Customer-owned rotation
  • Customer-owned audit trail
  • Broker and exchange credentials stay yours

Section 01 · Position

TradingHost is the runtime, not the vault.

TradingHost runs strategy code inside managed cloud runtimes. Your broker keys, exchange API keys, webhook secrets, signing keys and third-party data tokens should remain in your own secret store.

The secret store stays the source of truth. Your runtime receives the values it needs when the strategy starts. Your strategy reads those values using environment variables or a documented runtime fetch pattern.

TradingHost provides the deployment flow, runtime environment, logs, health checks, resource controls, region selection and MCP control surface around the strategy. It does not need to become the place where your trading credentials live.

This keeps the security boundary simple:

LayerResponsibility
Your secret storeHolds credentials, controls access and records audit history.
TradingHost runtimeRuns the strategy and exposes required values to the process.
Your strategyReads the values and connects to the broker, exchange or data provider.
Broker or exchangeAuthenticates the API key and enforces account-level permissions.

The result is a cleaner production model for automated trading: your code runs on TradingHost, while credential custody remains with you.

Section 02 · What counts as a secret?

Any private value your strategy needs to run.

A secret is any value that gives access to an account, service, connection or trading workflow if it leaks.

Common examples include:

  • Broker API keys
  • Exchange API keys
  • API secrets
  • Signing keys
  • Passphrases
  • Webhook secrets
  • Market data tokens
  • Database passwords
  • Private endpoint credentials
  • OAuth client secrets
  • Internal service tokens

A credential is a specific type of secret used to authenticate against a broker, exchange, data provider, database or third-party service.

Most trading credentials are not just a single value. They may include a key, a secret, a passphrase, an account ID, a sub-account ID, an environment name or a permission scope.

TradingHost treats these as runtime inputs, not as product data.

Section 03 · How secrets reach a runtime

From your secret store to your running strategy.

The runtime flow is intentionally familiar. It works like production application deployment, CI pipelines and modern cloud workloads.

  • Step 1

    Store the credential

    Keep the broker or exchange credential in the secret store you already use. That may be GitHub Actions secrets, HashiCorp Vault, AWS Secrets Manager, Doppler, 1Password Secrets Automation, Infisical, Bitwarden Secrets Manager or another compatible store. Your secret store stays the source of truth.

  • Step 2

    Deploy the runtime

    Your GitHub-driven deployment starts the TradingHost runtime. The runtime receives the values your strategy needs through the configured secret delivery pattern. For most strategies, those values are exposed as environment variables at startup.

  • Step 3

    Start the strategy

    Your strategy reads the variables, connects to the broker, exchange, market data provider or internal service, then begins running inside the TradingHost runtime. The trading relationship remains between your strategy and the venue.

Section 04 · Compatible secret stores

Use a secret store you already trust.

TradingHost is designed for external secret-source patterns. You do not need to move every broker or exchange credential into a TradingHost-owned vault just to run a strategy.

The providers below are the secret store patterns TradingHost documents first.

Secret storeBest fit
GitHub Actions secretsIf GitHub is already your source of truth for code and deployment workflows.
HashiCorp VaultIf you already use Vault for policies, dynamic secrets, short-lived tokens or HCP Vault.
AWS Secrets ManagerIf you live in AWS and rely on IAM, managed rotation and AWS audit tooling.
DopplerIf you want a simple secrets dashboard across environments.
1Password Secrets AutomationIf you already use 1Password vaults for credential management.
InfisicalIf you prefer an open-source secrets platform with self-hosting options.
Bitwarden Secrets ManagerIf you already use Bitwarden for password and secret workflows.
Bring your ownAny compatible store that can expose values through environment variables or a runtime fetch pattern.

TradingHost does not force you to abandon your existing security setup. If you already have a secret store, access model, rotation cadence and audit trail in place, the goal is to keep using it.

Section 05 · At a glance

The secrets model in plain English.

QuestionAnswer
Who holds custody?The customer.
Where should secrets live?In the customer's chosen secret store.
Is TradingHost the secret store?No.
Should secrets be committed to GitHub?No.
Should .env files be baked into images?No.
How does a strategy read secrets?Environment variables or documented runtime fetch patterns.
Who rotates credentials?The customer, through the secret store or broker / exchange account.
Who revokes leaked credentials?The customer, through the secret store, broker, exchange or data provider.
Where does the audit trail live?Primarily in the secret store, broker, exchange and deployment history.
Can secrets appear in logs?Only if the strategy prints them, which it should never do.
What does TradingHost see?Runtime metadata, deployment state, health signals and logs emitted by the process.
What can TradingHost staff see?No internal interface exposes customer broker or exchange credentials to TradingHost staff.

The important distinction is simple:

TradingHost runs the process. Your secret store governs the credentials.

Section 06 · What TradingHost does not need

No credential sprawl to run a strategy.

A trading runtime should not require loose copies of sensitive credentials across laptops, tickets, screenshots, chat messages, support tools, repositories and unmanaged .env files.

With TradingHost, you should not need to:

  • Hardcode broker keys in a repository
  • Bake .env files into container images
  • Paste exchange credentials into a generic dashboard
  • Send API keys to support staff
  • Store production secrets in spreadsheets
  • SSH into a server just to edit environment variables
  • Share keys over chat or email
  • Manually copy credentials between environments
  • Leave old keys alive because you have lost track of where they are used

The cleaner model is to keep secrets in one trusted place and let the runtime receive only what the strategy needs.

Section 07 · What stays yours

Credential governance remains under your control.

TradingHost provides the runtime. You keep control of the sensitive credential decisions.

You decide:

  • Which secret store to use
  • Which strategy can access which credential
  • Which broker or exchange account a key belongs to
  • Whether a key can trade, read balances, read positions, or withdraw funds
  • How often credentials are rotated
  • Who can view or modify production secrets
  • How revocation is handled
  • Where audit records are reviewed
  • Which environments can access live credentials
  • Whether separate keys are used for development, staging and production

This matters for trading infrastructure because API permissions can be financially sensitive. A broker or exchange key may grant access to balances, open positions, order placement, account history, or withdrawal functions.

TradingHost should not be the reason those permissions become harder to govern.

Section 08 · Runtime behaviour

Your strategy reads secrets like a production application.

A strategy deployed to TradingHost should treat secrets as runtime configuration.

For example:

  • Crypto strategy

    • EXCHANGE_NAME
    • EXCHANGE_API_KEY
    • EXCHANGE_API_SECRET
    • EXCHANGE_API_PASSPHRASE
    • TRADING_MODE

  • Broker-connected strategy

    • BROKER_NAME
    • BROKER_ACCOUNT_ID
    • BROKER_API_KEY
    • BROKER_API_SECRET
    • BROKER_ENVIRONMENT

  • Market-data strategy

    • DATA_PROVIDER
    • DATA_API_KEY
    • DATA_REGION
    • DATA_FEED

The exact variable names are defined by your project, framework, connector or deployment workflow.

TradingHost does not need to understand the private value itself. It only needs to give the running process a way to access the configuration it expects.

Section 09 · Logs and observability

Secrets should never be printed.

TradingHost provides runtime logs and health visibility so you can see whether a strategy is running, failing, restarting, connecting, or emitting errors.

Those logs are useful for production operations, but they are not a safe place for secrets.

Your strategy should never print:

  • API keys
  • API secrets
  • Signing payloads
  • Passphrases
  • Auth headers
  • Bearer tokens
  • Webhook secrets
  • Full connection strings
  • Raw environment dumps
  • Broker session tokens
  • Exchange authentication responses

TradingHost shows logs emitted by your process. If a strategy writes a secret to stdout, stderr, stack traces, debug output or error payloads, that value may become visible in runtime logs.

The safest pattern is to log connection state, not credential values.

  • Good

    • Connected to Binance spot account.

  • Bad

    • Connected to Binance using API key abc123...

Section 10 · Security boundary

The boundary, stated plainly.

TradingHost should not be treated as the system of record for broker or exchange credentials.

Your credentials should live in your own secret store, governed by your own access controls, rotation policies and audit process.

TradingHost should not require secrets to be committed to GitHub, baked into deployment images, added to .env files inside the container, or shared with support staff.

TradingHost provides the runtime layer around the strategy. Your strategy uses the configured runtime delivery pattern to access the values it needs. Your broker, exchange, data provider or internal service remains the system that authenticates the credential and enforces account-level permissions.

That separation is the point.

TradingHost runs the code.
You govern the keys.

Related

Where to go next

FAQ

Frequently asked questions

TradingHost is designed so your secret store remains the source of truth for broker and exchange credentials. The runtime receives the values your strategy needs through a configured secret delivery pattern, rather than asking you to hardcode keys or bake .env files into images.

No. Broker keys, exchange API keys, passphrases, signing keys and data-provider tokens should never be committed to a repository. Use GitHub Actions secrets, an external secret store, or another documented runtime secret pattern.

Your deployment image should not include a .env file containing live credentials. Secrets should be provided at runtime, not packaged into the codebase or image.

Most strategies read secrets from environment variables at startup. Some setups use a runtime fetch pattern from Vault, AWS Secrets Manager, Doppler, 1Password, Infisical, Bitwarden or another compatible store, depending on how the deployment workflow is configured.

Rotation happens in your secret store or directly at the broker, exchange or data provider. Once a credential is rotated, restart or redeploy the affected runtime so the strategy receives the new value.

Revoke the credential in the system that issued it. For trading keys, that usually means the broker, exchange, data provider or internal service. You should also remove or replace the value in your secret store.

Only if your strategy prints them. TradingHost shows logs emitted by your process, so strategies should never print credentials, environment dumps, auth headers, tokens, passphrases or raw connection strings.

TradingHost should not provide a staff-facing interface for reading customer broker or exchange credentials. Your own secret store should remain the place where access to credential values is governed and audited.

Yes. TradingHost is designed around external secret-source patterns. If your secret store can expose values through environment variables or a documented runtime fetch pattern, it can usually fit the TradingHost deployment model.

TradingHost documents patterns for GitHub Actions secrets, HashiCorp Vault, AWS Secrets Manager, Doppler, 1Password Secrets Automation, Infisical and Bitwarden Secrets Manager.

Bring your own secret store. Deploy with GitHub.

Connect GitHub, configure your runtime, and point your strategy at the secret store you already trust.

TradingHost runs the code.
You keep the keys.