support@build.io
10. Security
Security isn't a feature you bolt on—it's built into how Build.io operates. From the infrastructure your code runs on, to how your team accesses the platform, to how we handle your data, security is a core part of the service.
This section covers how to secure your Build.io account, manage team access, and follow best practices for keeping your applications safe.
10.1 Authentication and access control
Build.io supports two sign-in methods:
Email and password — Create a Build.io account with your email address and a strong password. Use a password manager to generate and store a unique password—don't reuse one from another service. Protect your account further by enabling two-factor authentication (see Section 10.3).
Google SSO — Sign in with your Google account for a streamlined login experience. This is particularly convenient for teams already using Google Workspace, as it lets you centralise identity management through your existing Google admin policies.
API Authentication
If you're interacting with Build.io programmatically—through the CLI or the Platform API—you authenticate using API tokens. API tokens are tied to your account and carry the same permissions you have in the dashboard.
Generate and manage API tokens from your account settings. Treat API tokens like passwords: don't commit them to repositories, don't share them over unencrypted channels, and rotate them periodically. If you suspect a token has been compromised, revoke it immediately from your account settings and generate a new one.
CLI Authentication
The bld CLI authenticates using an API token stored locally on your machine. When you first run bld login, you'll authenticate through your browser and the CLI stores the resulting token. On shared or CI machines, set the BUILD_API_KEY environment variable rather than running an interactive login. Alternatively, you can create/update a ~/.netrc file with the login as your username and the password as your API key and the bld CLI tool will read from this file and authenticate you appropriately.
10.2 Team management and permissions
Most applications are built by teams, and Build.io provides role-based access control so you can grant the right level of access to each team member.
Teams
Teams are the top-level unit for team collaboration on Build.io. A team owns apps, pipelines, and add-ons, and has members with defined roles. Using a team keeps your production infrastructure under shared ownership rather than tied to a single person's account.
Roles
Build.io has two roles:
Admin — Full control over the organization, its apps, billing, and members. Admins can add and remove members, change roles, create and destroy apps. Keep the number of admins small—most team members don't need this level of access.
Member — Can create apps, deploy, manage config vars, attach add-ons, and do everything needed for day-to-day development work. Members cannot add and remove other members.
Managing Access
Add members from the organization settings in the dashboard. When someone joins your team, add them as a Member unless they specifically need admin capabilities. When someone leaves, remove their access promptly—don't let inactive accounts linger with access to your production infrastructure.
Review your organization's member list periodically. It's easy for access to accumulate over time, especially on teams with contractor turnover or cross-functional collaborators who no longer need access.
10.3 Two-factor authentication
Two-factor authentication (2FA) adds a second verification step beyond your password when signing in. Even if your password is compromised, an attacker can't access your account without the second factor.
Enabling 2FA
Enable 2FA from your account security settings in the Build.io dashboard. Build.io supports authenticator apps (such as Google Authenticator, Authy, or 1Password) that generate time-based one-time passwords (TOTP). After enabling 2FA, you'll be prompted to enter a code from your authenticator app each time you sign in.
During setup, Build.io provides backup recovery codes. Store these somewhere safe and separate from your authenticator—they're your fallback if you lose access to your authenticator app. Each recovery code can only be used once.
2FA for Teams
If you manage a team on Build.io, strongly consider requiring 2FA for all organization members. A single compromised account can expose your entire production infrastructure—config vars, database credentials, deployment access, and everything else that account can reach. Making 2FA mandatory across your organization is one of the highest-impact security measures you can take.
10.4 Compliance and certifications
Build.io operates from Tier 4 data centres located across major internet hubs in the US (East and West), Western Europe, and Japan. Our infrastructure is designed to meet the security requirements of teams building production SaaS applications.
Security Team
Our team includes core contributors to prominent security tools and projects under the Cloud Native Computing Foundation, including Metasploit, Kubernetes, and Cilium. We have multiple CISSP-certified professionals and CREST CRT-certified penetration testers on staff. Security isn't outsourced—it's part of the team that builds and runs the platform.
Infrastructure Security
Build.io runs on Kubernetes with security-hardened defaults. Your application containers run in isolated namespaces with restricted privileges. Network policies enforce strict segmentation between tenants—your app's traffic cannot reach another customer's workloads.
All data is encrypted in transit using TLS and at rest using AES-256 encryption. Config vars, database credentials, and other secrets are encrypted at every stage of their lifecycle.
Compliance
If your organization has specific compliance requirements—SOC 2, ISO 27001, GDPR, or industry-specific regulations—reach out to our team at support@build.io to discuss how Build.io can support your compliance posture. We can provide details about our security controls, data handling practices, and infrastructure architecture as needed for your audits and assessments.
10.5 Security best practices
These are the most impactful things you can do to keep your applications secure on Build.io.
Protect Your Accounts
Enable two-factor authentication on every Build.io account in your organization (see Section 10.3). Use a password manager. Don't reuse passwords. Review your organization's member list regularly and remove inactive accounts. These basics prevent the vast majority of account-based attacks.
Keep Secrets Out of Your Code
Never commit API keys, database passwords, encryption keys, or other credentials to your repository. Use config vars (see Section 4.1) to inject secrets at runtime. If you accidentally commit a secret, consider it compromised immediately—rotate the credential, don't just delete the commit. Git history is permanent and may have already been cloned or cached.
Add a .env file to your .gitignore before your first commit. Use tools like git-secrets or pre-commit hooks to catch accidental credential commits before they're pushed.
Rotate Credentials Regularly
Don't wait for a breach to rotate your secrets. Set a schedule—quarterly is a reasonable starting point for most teams—and rotate API keys, database passwords, and other long-lived credentials. Use the config var update process (Section 4.3) to make rotation straightforward.
When rotating, update the new credential in your config vars and verify your app works before revoking the old one. Some services support multiple active credentials simultaneously, which allows zero-downtime rotation.
Keep Dependencies Updated
Outdated dependencies are one of the most common attack vectors. Use your language's dependency audit tools (bundle audit for Ruby, npm audit for Node.js, pip-audit for Python) and address vulnerabilities promptly. Automated tools like Dependabot can open pull requests for vulnerable dependencies, and your Build.io pipeline and review apps make it easy to test those updates before they reach production.
Use the Web Application Firewall
Enable Build.io's built-in WAF (see Section 4.2) for any app exposed to the public internet. The WAF blocks common attack patterns like SQL injection and cross-site scripting with minimal configuration and negligible performance impact. It's not a substitute for secure application code, but it provides a meaningful layer of defence against automated attacks and opportunistic scanning.
Limit Your Attack Surface
Only expose what needs to be exposed. If a service doesn't need to be reachable from the public internet, don't give it a public URL. Disable features and endpoints you don't use. Every open port, public endpoint, and enabled service is a potential entry point.