Secrets are configuration
Bot tokens and API keys should be supplied separately from source code. The product is designed to pass secret configuration to the intended workload rather than asking users to commit it.
Never place a bot token in Git.
Trust / Security
Bot tokens deserve
production discipline.
A Discord bot host sits close to code, credentials, and community data. Our security approach starts by treating each of those as a separate responsibility with a narrow access path.
Security model
Separate the code, the credential, and the running process.
Security is strongest when sensitive values have fewer places to travel. These are the product boundaries BotHoster is being built around.
Scoped data access
Customer-facing data access is designed around authenticated ownership boundaries, so an account can work with its own bots, deployments, and operational events.
Access follows identity and ownership.
Workload boundaries
Hosted bot processes are designed to run as containerized workloads with resource boundaries instead of sharing one unconstrained application process.
Isolation is a layer, not a substitute for safe code.
Purposeful logs
Operational logs should help diagnose a process without becoming a second secret store. Tokens and resolved secret values do not belong in log output.
Useful context, minimal exposure.
Explicit process state
Starting, running, stopping, crashing, and failing are distinct conditions. Representing them clearly makes unexpected behavior easier to identify and investigate.
Visible failure is safer than silent ambiguity.
Conservative permissions
BotHoster encourages Discord bot makers to request the Gateway intents and server permissions their features need—not broad access by default.
Least privilege on both sides of the connection.
Shared responsibility
The platform can protect a boundary. Your bot still owns its behavior.
Hosting security and application security overlap, but they are not the same thing. BotHoster manages the hosting surface; bot makers remain responsible for the code and Discord access they choose.
BotHoster boundary
Hosting and control plane
- Authentication and account-scoped product access
- Runtime configuration delivery and process orchestration
- Workload and resource boundaries on managed infrastructure
- Operational state and log transport within the product
Bot maker boundary
Code and Discord access
- Dependencies, source code, and application vulnerabilities
- Discord intents, install scopes, and server permissions
- Data collected or stored by the bot itself
- Rotating credentials after a suspected external exposure
For bot makers
Four habits that prevent the most avoidable token incidents.
1. Keep credentials out of source control
Load the Discord token and third-party API keys from environment variables. Add local configuration files such as .env to .gitignore before the first commit, and scan the staged diff before pushing.
2. Rotate first, investigate second
If a bot token may have appeared in a repository, log, screenshot, or chat, reset it in the Discord Developer Portal. Removing a leaked string from the latest commit does not make the old credential safe again.
3. Request the smallest useful Discord access
Enable only the Gateway intents the bot consumes and install it with only the server permissions its features require. Review access again when a feature is removed.
4. Treat dependencies as part of the bot
Keep the lockfile in source control, review dependency changes, and update maintained libraries deliberately. A hosting layer cannot make an unsafe package safe.
Disclosure
Found a security concern? Tell us directly.
Please avoid testing against accounts, bots, or infrastructure you do not own. Send a clear report with the affected surface, reproduction steps, and impact.
Security contact
hi@bothoster.devDo not include active credentials in the report. If a Discord bot token is exposed, reset it before contacting us.
Security questions
Plain answers about sensitive bot data.
Should I commit a Discord bot token to a private repository?
No. Keep the token in environment configuration. Private repositories still have collaborators, integrations, logs, exports, and the possibility of a later visibility change.
What should I do if my token is exposed?
Reset the token in the Discord Developer Portal immediately, update the hosted environment, and review logs and recent bot activity. Removing the old token from a file is not enough.
Does containerization make any bot code safe?
No. Workload boundaries reduce certain kinds of impact, but bot makers still need to review code and dependencies, constrain Discord permissions, and handle community data responsibly.
Related reading
See the rest of the operating model.
bothoster.dev/discord
Discord bot fundamentals
Review tokens, intents, permissions, and Gateway connections.
Read more →bothoster.dev/discord-bot-hostingHosting workflow
Understand the path from repository to running bot process.
Read more →bothoster.dev/aboutAbout BotHoster
Read the principles behind the product and its early-access stage.
Read more →Next step
Build the bot. Protect the credential.
Join BotHoster early access for a hosting workflow designed to keep source, secrets, and runtime configuration in their proper places.