Terraform License Agreement
To follow the terraform license agreement, check how your team runs the tool and whether you sell a competing service. Most teams can run the tool to build and manage their own cloud apps at no cost. Teams often start by sharing cloud admin keys on laptops so everyone can run plans. When those roles are too broad, one bad run can wipe out live data or leak keys in state files. How the terraform license agreement works in practice HashiCorp moved its core code from an open source license to th
Terraform Security (tfsec, Checkov): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To follow the terraform license agreement, check how your team runs the tool and whether you sell a competing service. Most teams can run the tool to build and manage their own cloud apps at no cost. Teams often start by sharing cloud admin keys on laptops so everyone can run plans. When those roles are too broad, one bad run can wipe out live data or leak keys in state files.
How the terraform license agreement works in practice
HashiCorp moved its core code from an open source license to the Business Source License. Under the terraform license agreement, internal use stays free for almost every company. You can write code, run plans, and update your own cloud resources every day. You can also run the tool inside your own internal build pipelines.
The rule changes if you build a hosted product around the tool and sell it to outside buyers. If your app wraps the binary to compete with the vendor's paid cloud product, you need a commercial deal. Standard consulting work and building apps for your own business do not break this rule.
To check your setup, list every place where your team runs the tool. Look at local laptops, build servers, and shared cloud runners. Make sure those workflows only manage your own company servers, databases, and networks. Keep a record of the version your team uses so legal reviewers can check the exact terms.
How teams set up roles and permissions for state
Once legal terms are clear, teams must set up safe cloud roles for state files and runs. The tool needs cloud permissions to read current servers and create new ones. It also needs a safe bucket or database to store the state file after each run. That state file holds plain text details about every resource you build.
Many teams begin by giving developers full admin roles so their plans do not fail. A developer logs in on a laptop and runs an update against the live account. The tool reads the state file, checks the cloud API, and makes the changes right away. Moving runs to a build server helps, because the build server holds the cloud keys instead of laptops.
Even with a build server, engineers often need direct database or server sessions to fix failed runs. When a state lock hangs or a database script fails, someone logs in to fix it by hand. Teams then hand out broad roles so on-call staff can read state data and run repair commands.
Terraform Security (tfsec, Checkov): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native cloud roles solve and what they miss
Cloud roles and state locks decide who can start a run or read a bucket. They stop outside users from reading your state files or launching servers in your account. They also let you separate test accounts from live accounts using different login roles.
Still, static cloud roles only check who logs in at the start of a session. They do not inspect what individual commands or queries do once the session is open. If an engineer has a role to fix a broken state or database, they have full power during that login.
A single mistyped command can drop a live table or expose private records in terminal logs. State files and database rows often hold sensitive values like emails, phone numbers, card numbers, or national IDs. Native role setups do not mask those fields in query results or require approval for risky commands in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can my team use the tool for free at work?
Yes, you can use it for free to build and manage your own company systems. You only need a paid deal if you embed the tool in a product that competes with the vendor.
What happens if we stay on an older open source version?
Older versions before the license change stay under the Mozilla Public License forever. You can run and modify those old versions under the old rules, but they do not get new features.
Why are state files a risk for team permissions?
State files store resource details and secret keys in plain text. Anyone with read permissions on the state bucket can see those keys and use them to log in to live databases.