Thank you for your vote, register to receive notifications and updates
Brainboard Cloud | Changelog
Explore our Terraform development updates on our public roadmap changelog. Discover new features and integrations regularly. Check in weekly, monthly, or quarterly to see the latest enhancements benefiting your business.
For our Enterprise customers, you have the possibility now to self-host a private Brainboard runner within your infrastructure. This gives you more control on the execution as it happens in your private infrastructure.
If you are interested in this feature, please reach out to us: support@brainboard.co
Now, you have the capability to retrigger any previously run workflow directly from the listing view, without needing to go to the workflow designer view.
You can now interact with Brainboard programmatically and trigger any workflow through our API.
For example, you can design your infrastructure/generate terraform code, push it to your git repository and then automatically trigger the provisioning workflow from your pipeline.
Checkov Integration: Checkov is now reintegrated, enhancing our security scanning capabilities.
OPA Job Status: We've improved the OPA job status to now fail when the result is empty, ensuring more accurate feedback.
New Status for Partial Success: Responding to your requests, we've added a new status for scenarios where the job or pipeline succeeds despite some jobs failing.
Visual Enhancements: All job and pipeline statuses have been updated with new colors and icons for clearer visual representation.
Two new CI/CD Plugins enabling efficient collaboration and streamlined code reviews.
Pull Request: create directly inside your workflow/pipeline the Pull Request once all other validations and test pass.
Microsoft Teams: get a notification in your Teams once a pipeline succeed
Unlimited Terraform code generation for free: You can enjoy the benefits of streamlining your design to code generation without any cost, making it an ideal choice for small-scale projects and personal use.
Use markdown text in the design area: The enrichment text feature enhances the quality and context of written content and notes on top of your diagram, providing valuable insights and improving overall readability and comprehension of your infrastructure.
🐞 Fixes:
Git configuration
Git configuration now offers improved validation mechanisms to ensure the correctness of settings, reducing the occurrence of configuration errors.
The changes made in Git configuration are now saved automatically, eliminating the need for manual saving and preventing accidental data loss.
Instead of encountering scope conflict errors, Git configuration now notifies users of already existing errors, allowing for easier resolution and smoother configuration management.
The new loading provides a seamless and responsive user experience, enhancing the overall efficiency of your Terraform configuration process.
The cloud providers credentials forms and validation have been enhanced, making it easier to manage and validate credentials for cloud services.
In the CI/CD output, auto-scrolling is disabled when users scroll up, allowing them to review and analyze the output without interruption.
When removing all characters in the ID card field, the focus no longer disappears, providing a smoother user interaction and improving data entry experience.
Pull request plugin in the CI/CD workflow: We are excited to announce the successful integration of a new feature within Brainboard's CI/CD workflow - the Pull Request (PR) plugin. This integration empowers users to trigger PR creation directly within their Brainboard workflow, streamlining the development process and promoting collaboration among team members.
Legacy use-case: If you use Terraform or IaC to deploy your infrastructure, you either need to have the tests locally (heavy to maintain) or push to the CI and do tests there (you spend your time waiting).
✅ With Brainboard, you can make sure that your work is clean BEFORE you push into git by using the robust CI/CD engine to check while you are building the infrastructure
For e.g. do security checks, cost estimations, policy enforcement then automatically do a PR if all checks are green.
Git Source Update: When using a module from a Git source, Brainboard automatically fetches the latest update. However, there are instances where this automatic update fails to occur. In such cases, manual synchronization is required to ensure the latest module version is obtained.
Module Update Inconsistency: When making changes to a custom source module, Brainboard fails to update all architectures that use this module consistently. This leads to outdated module versions being used in some architectures.
Improved Manual Synchronization: We have implemented enhancements to the manual synchronization feature for modules sourced from Git. Brainboard now reliably fetches the latest module update when initiated manually. This ensures that users have access to the most up-to-date version of the module.
Inheritance System Issue: For a specific period of one day, there was a problem with the inheritance system. The issue caused inconsistencies and unexpected behavior when inheriting modules. However, the problem was identified and fixed on the same day.
Code Fix for Network Ranges and IPs: We have resolved an issue related to code changes that involve network ranges and IP addresses. The fix ensures accurate handling and processing of these elements.
Improved Variable Creation from ID Card Field: The process of automatically creating variables from the ID card field has been enhanced. The improvements aim to provide better accuracy and reliability when generating variables from this specific field.
Import modules: When importing modules that already exist, we display the appropriate error message to better explain the root cause of the issue.
Git Integrations: Error messages that prevented the saving of Git configurations have been resolved.
Deploy: We noticed an issue with the Deploy tab causing infinite loading, which affected a few architectures. We resolved the problem immediately and apologize for any errors this may have caused and any impact on your deployment cycle.
Terraform Plan: The Plan button was malfunctioning and displaying a warning about the concurrency limit, which was not intended. We apologize for any confusion or inconvenience this may have caused. The issue has been addressed and the warning will no longer appear.
We apologize for any inconvenience this may have caused, and thank you for bringing it to our attention.
Please note that the above issues have been resolved in the latest version of Brainboard and should no longer occur.
We're excited to announce that the CI/CD Engine has been improved with new features to improve infrastructure management for our users.
One of the most exciting new features is the drift detection capability, which allows engineers to stay on top of their infrastructure by notifying responsible parties in case of drift, scheduling workflows for better optimized timing, and maintaining order while another workflow is active. Drift Detection output with a change detected
Other new features include:
Multiple workflows: With Brainboard's CI/CD Engine redesign, you can now create multiple workflows, providing greater flexibility and customization options for designing and implementing projects.
CI/CD workflow templates: With Brainboard's CI/CD Engine, you can create workflow templates that you and your team can reuse to streamline your workflow and optimize your infrastructure management.
Scheduled workflows: Brainboard's CI/CD Engine allows you to schedule workflows to be launched at any desired time. This ensures that workflows are being executed at the best optimized timing for your infrastructure management needs.
Notifying on pipeline failure: Notifying someone when drift is detected on cloud infrastructure can help prevent issues such as security vulnerabilities, compliance violations, and performance problems. By detecting drift early and addressing it promptly, IT teams can investigate and remediate any issues before they cause substantial damage, ensuring that the infrastructure remains secure, reliable, and operating as expected.
These features provide greater flexibility and customization options for engineers when designing and implementing projects.
We understand the importance of ensuring infrastructure security and reliability, and these new features were designed with that in mind. We hope that our users will find them useful in streamlining their workflow and optimizing their infrastructure management.
As part of our efforts to enhance the user experience, we have made significant improvements to Brainboard's Terraform Code and One Action features. In addition, we have also introduced a new capability that allows users to view the Terraform Plan output directly while visualizing their cloud architecture and comprehending their Terraform code.
These updates enable Brainboard users to accelerate their infrastructure changes and monitor them all at once, while ensuring safe and reliable deployment.
Multi-Workflow Capability: You can now create and manage multiple workflows for your CI/CD pipeline, making it easier to organize and streamline your development process.
Drift Detection: Our new drift detection feature helps you identify and resolve configuration differences between your development, staging, and production environments.
Notification Sending: You can configure notifications to be sent to relevant stakeholders, keeping everyone informed about the status of builds, deployments, and releases — including when pipelines fail.
Approval Tasks: We’ve introduced approval tasks to enable more granular control over the deployment process. This feature lets you define a set of approvers who need to sign off on each deployment before it can proceed.
Scheduled Deployment: You can now schedule deployments for a specific time and date, allowing you to plan ahead and ensure that new releases are rolled out at a time that suits your team and your customers.
In the CI/CD Engine, we've been adding approval tasks enabling cloud architects to ask for review / approval before, during or after the deployment. Now, this task has improved, enabling seamless email notifications.
The import functionality has been improved to address the problem of internal errors. Error handling has been optimized and the dependencies between resources are now managed more effectively.
CI/CD Approval task — List of suggested users:
The user experience when deploying cloud infrastructure through the CI/CD Engine has been improved. Users now have the ability to choose from a list of suggested users when approving a task, eliminating mis-suggestions.
Configuring resources when selecting a node
The user experience has been improved when selecting resources through the Design Area or TF Code. Now, the ID Card will open automatically when clicking on a resource name.
Data inheritance not implemented when importing:
The inheritance of data sources when importing TF files has been implemented. For example, when a data subnet is inside a data virtual network, it will now be depicted as such in the TF code.
Templates' catalog ownership:
The "by" section in the Template Catalog has been updated to include all relevant authors. This ensures proper attribution and recognition.
Initiator name is missing in pipeline output:
The name of the person triggering the pipeline is now included in the pipeline View, providing visibility into who is responsible for launching which pipeline and when.
We apologize for any inconvenience this may have caused, and thank you for bringing it to our attention.
Performance: Performance in the canvas area of Brainboard has been improved gradually, especially with small architecture and very big architectures (500+ nodes). This should result in faster load times and a smoother user experience.
Documentation: A new documentation was just released, improving product clarification and explanation. This improved documentation will help users better understand our product and how to best use it. Get excited about next week's website launch, featuring brand-new features and a more modern design! You can visit the documentation here.
Specify a different brand when doing a pull request:
We now allow you to specify a different branch in the base branch field in the pull request modal, when creating a pull request. This means that you are able to select which branch they want to merge their changes into, rather than being restricted to a specific branch such as “main”. This feature can be useful for organizations that use multiple branches for development and testing, as it allows developers to easily collaborate on code changes and merge them into the appropriate branch for deployment. Additionally, it can help to maintain the versioning and history of the Terraform codebase.
Variable type not saved:
Problem: This bug fix addresses an issue where a new variable is not correctly saving the type information during the creation or modification process. This can cause problems with the functionality of the application, as the type of variable is important for determining how the application should handle and interact with the variable's value.
Solution: The fix involves updating the Terraform code that is responsible for handling the creation and modification of variables to properly save the type information. This could involve checking for missing or incorrect type information, and adding code to handle this properly. Additionally, it also involves testing the updated Terraform code to ensure that the bug is resolved and that the new variables are being created and modified correctly with the correct type information.
Custom group TF file broken:
Problem: The bug fix addresses an issue with the functionality that retrieves custom group files in Terraform. The bug is related to the fact that when a group starts with 'f' or 't' the retrieval of the custom group file is broken. The issue with the Terraform configuration for the “test” group, as the test.tf file should contain the necessary information for provisioning and managing the infrastructure for that group, but it is empty.
Solution: Create an architecture or a blueprint of the infrastructure using Terraform. Add 3–4 nodes on the design canvas, which are servers or machines that make up the cloud infrastructure. Change the group of 2 of the nodes to “test” group. Now, retrieve the test.tf file, which should contain the Terraform configuration for the “test” group.
Scroll through a big output:
Problem: The bug fix addresses an issue with the performance of scrolling through the output of the “plan” in Terraform. The bug is causing the scrolling to be slow and unresponsive, with a delay of 2–3 seconds before the update or the next lines are displayed.
Solution: We optimized the code that handles the output display and scrolling by reducing the number of updates and unnecessary calculations. We always make sure the data is being loaded and processed efficiently.
ImportMultiple strings:
Problem: The bug fix addresses an issue with the way Brainboard import Terraform code that contains "<<EOF" and "EOF" for a field. The bug causes these characters to be changed into strings which causes issues in the interpretation of the code.
Solution: Update the import code to properly handle these characters. We make sure the code that reads and interpret the imported Terraform code is able to handle these characters correctly.
Feedback survey:
Problem: We noticed that the feedback form brought aggressive prompts to you, builders and cloud architects.
Solution: We've disabled it for now. Please continue to contribute to the Slack community and contact us if any improvements need to be fixed. We generally respond within 6h.
Problem: The bug fixes you addresses an issue with the way the editing of the title of a node behaves in Brainboard's canvas. The bug causes the title of the selected node to change when editing the title of a different node that is not selected.
Solution: We added a check to verify that the correct node is being edited, or by making sure the system is keeping track of the correct selected node.
We apologize for any inconvenience this may have caused, and thank you for bringing it to our attention.
CI/CD Engine: We've just introduced a feature for approval tasks, which allows users to request and receive approval before deploying code changes to a production environment. This can be useful for ensuring that code changes have been reviewed and tested properly before they are deployed to a live environment, and can help to prevent errors or issues that could negatively impact the performance or functionality of the system.
Import: We continue to improve the import feature. This week, we've focused on database use case. Now, you can import schema and documentation. A schema is the structure of the database and the rules on how the data should be organized, while a document is a single unit of data stored within the database.
Deleting cloud architectures: When soft-deleting cloud architectures, we now soft delete all related objects including workflow(s), pipelines, jobs, deployments, git integrations, and terraform settings.
This should result in faster load times and a smoother user experience.
You can now watch last Tuesday's webinar on the details and implications of what CI/CD means for the cloud infrastructure. This is a short preview of what you will learn in less than 70 minutes:
Problem: When creating a new Storage Container in Brainboard, if the container already exists in AWS or Azure, the application would fail.
Solution: We have implemented a check that verifies if the container already exists in the specified cloud provider before attempting to create it. If the container already exists, Brainboard will no longer fail and will instead display a message indicating that the container already exists.
Git Personal Token Editing Error:
Problem: When editing only one field in the Git Personal Token, an error occurred and the changes were not saved.
Solution: We have identified the problem and fixed the issue with the Git Personal Token editing process. Users should now be able to edit any field in the token without encountering errors.
Terraform Block Removal:
Problem: When importing Terraform files, such as backend.tf that contains a Terraform block and many providers block, the Terraform block was automatically removed.
Solution: We have identified the problem and fixed the issue with the Terraform block removal during import. The Terraform block should now be retained and not removed during the import process.
Map variable syntax issue:
Problem: When importing a Terraform file that contains a map as the type of variable and the values are defined in terraform.tfvars, the values were changed and replaced with an invalid Terraform syntax, causing the plan to fail,
Solution: We have identified the problem and fixed the issue with the map variable syntax. The values should now be imported correctly and retain their original syntax.
Validation Block Import:
Problem: When importing from Git or files, for example, a Terraform code that contains a validation block, the variables validation block was not imported in Brainboard.
Solution: We have identified the problem and fixed the issue with the validation block import. The variables validation block should now be imported correctly and be visible in Brainboard.
Terraform Variables Modal:
Problem: The Terraform variable modal was changing every time it was opened or when doing a pull request. This caused confusion and made it difficult to track changes.
Solution: We have made changes to the Terraform variable modal, so it will no longer change every time it is opened or when doing a pull request. This will make it easier to track changes and manage variables.
Default Terraform Code File:
Problem: The default Terraform code file was main.tf, but it was causing confusion when working on a different resource file.
Solution: We have changed the default Terraform code file to be the resource file that the user is currently working on. This will make it easier to manage multiple resource files and keep track of changes.
We apologize for any inconvenience this may have caused, and thank you for bringing it to our attention.
Improve the error handling in the CI/CD (Continuous Integration/Continuous Deployment) engine of Brainboard. Specifically, the improvement is related to the handling of errors that occur during the use of web sockets.
*Web sockets are a technology that allows for real-time, two-way communication between a client and a server over a single, long-lived connection. In the context of CI/CD, web sockets may facilitate communication between Brainboard's CI/CD engine and other system components, such as the version control repository or the deployment pipeline.
The improved error handling in this feature ensures that any errors that occur during web sockets are handled more effectively, allowing a seamless CI/CD process to continue functioning even in the event of an error.
Visually design and orchestrate your deployment workflows without a single line of code.
Connect your automation ecosystem with OPA, Infracost, Checkov, or Terrascan…
Centralize your custom automation strategies and remote-run deployments.
Execute, optimize and manage workflows for successful outputs.
One of the biggest added values in terms of deployment is that Brainboard manages the upgrades and maintenance of the supported plugins: Infracost, OPA…
Brainboard have made significant improvements to the process of configuring cloud resources, specifically in regard to the identification and management of each resource. This is an essential task when building an architecture diagram, and we recognized the need for a more streamlined and efficient approach.
We have completely redesigned the concept of configuring a cloud resource, with a focus on simplifying the process and reducing the number of steps required. This has been achieved through the integration of more advanced automation techniques and the use of more intuitive user interfaces.
In addition to this, we have also made improvements to the design to code feature, which allows for a more seamless transition between designing the architecture diagram and configuring the relevant code. The combination of these two features results in a much smoother overall experience for the user.
I have personally tested these new features and can confidently say that it is a significant improvement from the previous version. I highly recommend giving it a try for yourself and see the difference.
At Brainboard, we've worked hard to take your experience with the Cloud to the next level, especially while managing Git credentials in teams.
We've enabled you to:
As an individual contributor, you can add personal git tokens for any supported git provider - Azure DevOps, Gitlab, Bitbucket - and specify the scope of the creds and have visibility on where they are used.
As the owner of the organization, you can add Github app integration and users perform git actions based on their authorization on Github.
What do you need to do:
The Git credentials of your organizations are assigned to the owner of the organization. So you need to add your personal token in order to do pull requests.
If you use GitHub, there is nothing to do. Your pull requests work as before.
Pull requests: Choose the git provider to use from the supported ones - Azure DevOps, Gitlab, Bitbucket, GitHub, and add the description, project, folder, and base branch within the service.
Modules: You can choose which git credentials you want to use to import your private modules and use them.
Generate your diagram from the terraform code: Choose the git credentials you want to use and import your existing terraform code.
Both categories, git apps and personal tokens, are available on the 'Account' configurations, here:
This new set-up capability enables the seamless performance of tasks without switching between accounts and re-authenticating accesses, and so work independently and well.
🚀 Do not commit/push .terraform/ folder during PR/MR
The feature being mentioned in this statement is related to the management of the .terraform/ folder in Brainboard, a cloud management solution. The issue being addressed is that when a pull request (PR) or merge request (MR) is made, too many files were being pushed, including the .terraform/ folder and its contents, such as terraform.tfstates.
The development team has implemented a feature that prevents the .terraform/ folder from being committed or pushed during a PR or MR. This means that when a user makes a PR or MR, the .terraform/ folder and its contents will not be included in the changes being pushed to the remote repository.
The .terraform/ folder is used to store the state of the resources in your Terraform configuration and it's sensitive data. So, it's not recommended to share it with others. By not committing/pushing this folder during PR/MR, it ensures that sensitive data is not accidentally shared with others, and it also reduces the amount of data being pushed, which can improve the performance of the PR/MR process.
In summary, the feature prevents the .terraform/ folder from being committed or pushed during a pull request or merge request in Brainboard. This ensures that sensitive data is not accidentally shared with others, and it also reduces the amount of data being pushed, which can improve the performance of the PR/MR process.
The issue being addressed is that when a user changes the version of Terraform to a newer one, the backend prompts them to migrate the state, but the version of Terraform is not updated in the frontend.
The development team has fixed this issue and now when a user changes the version of Terraform, the version is also updated in the frontend, and the user is able to perform actions such as plan, apply and destroy. This ensures that the user is always working with the correct version of Terraform, which can prevent errors and improve the stability of the platform.
*Terraform deployment is the process of creating, updating and deleting resources in an infrastructure, using Terraform HashiCorp Configuration Language (HCL) and Terraform API.
When you run terraform plan command, it compares the current state of infrastructure with the desired state, defined in the Terraform code, and it shows the changes that will be made to the infrastructure.
When you run terraform apply command, it applies the changes, defined in the plan to the infrastructure.
When you run terraform destroy command, it removes all resources, defined in the Terraform code from the infrastructure.
During this process, Terraform keeps track of the current state of the infrastructure in a state file, which is usually stored in a remote backend, such as AWS S3, and it can also be stored in a local file.
In summary, the feature fixed the issue with Terraform version change in deployment, where the version of Terraform is not updated in the frontend, causing difficulties for users to perform actions like plan, apply and destroy.
Version and deploy your cloud architecture with Brainboard.
*Bitbucket is a Git-based source code repository hosting service owned by Atlassian. It allows users to store, manage, and collaborate on their source code projects, using Git as the version control system. Bitbucket supports both public and private repositories, and provides features such as pull requests, code review, and issue tracking to help teams collaborate on code development.
The feature of integrating Bitbucket into the workflow means that users can now connect their Bitbucket repositories to other tools and services that they use, so that their code and development process can be seamlessly integrated into their overall workflow. This could include integrating Bitbucket with continuous integration and continuous delivery (CI/CD) tools, project management tools, or other code collaboration tools.
For example, users could connect their Bitbucket repository with a CI/CD tool like Jenkins to automate the process of building, testing, and deploying their code. They could also connect Bitbucket with a project management tool like Jira to track issues and tasks related to their code development process.
By integrating Bitbucket into Brainboard, users can streamline their development process and increase efficiency by eliminating the need to manually switch between different tools and services. Additionally, it can also facilitate collaboration and communication among team members by connecting their tools and services.
Integration of GitHub and GitLab with Brainboard. Brainboard is a tool that allows users to design and manage their infrastructure as code. With this new native integration, users can now automatically push the code generated by Brainboard to their preferred Git-based repository, such as GitHub or GitLab.
This integration allows users to benefit from the capabilities of Brainboard, such as visualizing their infrastructure and generating Terraform code, while also being able to store their code in a trusted repository. By storing their code in a repository, users can take advantage of features such as version control, code review, and collaboration.
Brainboard already supports other Git-based repository hosting services, such as Bitbucket and Azure DevOps. This means that users have multiple options for where to store their code and can choose the repository hosting service that best fits their needs and workflow.
The feature also states that Brainboard continues to integrate the infrastructure with today's workforce, without jumping the whole team into Gits. This means that users can use Brainboard to design and manage their infrastructure as code, without needing to be experts in Git or other repository hosting services. This feature is meant to make it easy for users to take advantage of the benefits of infrastructure as code, even if they don't have a lot of experience with Git or other repository hosting services.
.png)
