Moltbot is a powerful automation and crawling tool, but like any service that executes commands and processes external content, it must be properly secured. This is especially important when Moltbot is installed manually on a VPS, where insecure default settings can expose your server to serious risks.
If you deploy Moltbot using the Hostinger Docker Catalog, some critical security measures are automatically applied, such as assigning a random port and configuring gateway authentication. However, additional hardening steps are still required and must be handled by you to ensure a production-ready and secure setup.
This guide explains the most common Moltbot security risks and how to mitigate them.
What Hostinger secures by default (Docker Catalog install)
When Moltbot is deployed via the Hostinger Docker Catalog, we already take care of several essential protections:
The Moltbot gateway is not exposed on a fixed or well-known port, reducing the risk of automated scans and brute-force attacks.
Gateway authentication is enabled using a secure gateway.auth.token, preventing unauthenticated access to the API.
These measures significantly reduce the attack surface, but they are not sufficient on their own.
Essential Moltbot hardening steps you must configure
Restrict DM (Direct Messaging) Policies
By default, permissive DM policies may allow unintended users or actions. Configure your DM policy to explicitly allow only the users, roles, or actions you need. Avoid wildcard or “allow all” rules in production environments.
Enable Sandbox Mode
Running Moltbot without sandboxing allows commands to execute with fewer restrictions. Always enable sandbox mode and, if using Docker, disable external network access for sandboxed tasks unless absolutely required. This prevents malicious or compromised prompts from accessing your system or network.
Protect Credentials and Secrets
Credentials stored in plain-text configuration files are a common failure point. Use environment variables for tokens, API keys, and secrets. Ensure sensitive files have strict permissions (for example, readable only by the Moltbot process owner).
Defend Against Prompt Injection
Moltbot often processes web content, user input, or external data. Treat all external input as untrusted. Wrap untrusted content in explicit “untrusted” boundaries and avoid allowing it to directly influence command execution or tool invocation.
Block Dangerous Commands
Certain commands should never be available to Moltbot tasks. Explicitly block destructive or irreversible commands such as recursive deletes, forced git pushes, shell piping, or arbitrary network calls unless they are strictly required for your use case.
Enforce Network Isolation
If Moltbot runs in Docker, place it in an isolated Docker network. Avoid giving it access to your internal services, databases, or management interfaces unless necessary. Network isolation limits the blast radius if Moltbot is compromised.
Limit Tool Permissions
Only enable the MCP tools Moltbot actually needs. Granting broad or elevated tool access increases risk and violates the principle of least privilege. Review tool permissions regularly as your setup evolves.
Enable Audit and Session Logging
Without logging, security incidents are difficult to detect and investigate. Enable comprehensive session and action logging to track what Moltbot executes, when it runs, and who triggered it.
Secure Pairing and Access Codes
If Moltbot uses pairing codes or tokens, use cryptographically secure random values and apply rate limiting to prevent brute-force attempts.