The Blackfire Stack is made of five main components:
The following schema describes the general workflow of Blackfire and the communications established between each of its components.
At Blackfire, we take the security and confidentiality topic very seriously, to ensure the best experience possible while avoiding collecting unnecessary data, and provide safe authentication and hosting methods.
In a blink, here’s what we do, and do not do:
You can have a clear vision of the data sent to our servers by using a proxy between the Blackfire Agent and the Blackfire Servers. We released a PHP script that can help you in doing so.
Blackfire has been audited by an expert third party and is fully GDPR compliant.
Blackfire is not collecting any end user data.
A Data Processing Addendum may be required to be signed between two parties, a Controller and a Processor. A Controller collects personal information from its users. A Processor can get some of that data from the Controller, and process it, as the value it provides to the Controller.
Blackfire is not a Processor of any data you collect from your users. There is therefore no need for you to have a Data Processing Addendum with Blackfire.
When configuring Blackfire to run performance test scenarios on your application,
the Blackfire servers need access to your application’s servers.
If the profiled application is behind a firewall, let the Blackfire servers
access the application by allowing IPs
your configuration for the web ports (usually
@1 are appended when functions or methods are invoked
recursively - which means they call themselves. The number following the
represents the level of nesting.
For regular usages, you should never hit 1,000 profiles per day per user.
For regular usages, you should never hit 350 builds per day per user.
Blackfire dropped its current beta support of Go. An OpenTelemetry-based solution is being developed to better handle Go applications in the future.