Heavy WebGL Workloads Are Not Supported Yet
Certyn supports self-hosted runners today, but heavy WebGL and GPU-backed browser workloads are not supported yet. Here is what that means and what we plan to add.
Certyn supports self-hosted runners today. You can run browser automation inside your own network, on your own infrastructure, with your own Docker capacity.
What we do not support today is heavy WebGL usage or true GPU-backed browser execution for those session containers.
That distinction matters.
When teams ask for "GPU support" in a browser automation container, they usually mean one of two different things:
- Make WebGL pages render at all
- Run the browser with real hardware acceleration
For lightweight compatibility cases, software rendering can help. For heavy graphics scenarios, it is not enough.
The Short Answer
Current position:
- Self-hosted runners: available today
- Heavy WebGL scenarios: not supported today
- Real GPU-backed browser execution: planned, not available yet
If your product depends on demanding WebGL scenes, graphics-intensive canvas work, or hardware-backed browser rendering, Certyn should not currently be positioned as supporting that workload.
What We Mean by "Heavy WebGL"
Examples include:
- 3D-heavy product surfaces
- map or canvas experiences with large scenes
- apps that are materially different under hardware vs software rendering
- cases where rendering performance itself is part of what you need to validate
These are different from simpler cases where a page just needs WebGL enabled to avoid a blank area or degraded fallback path.
Why This Is Not Supported Today
The current browser container path is designed for reliable automation, live viewing, and recording inside Docker. That is a good fit for general browser testing. It is not yet a GPU-first runtime.
Two things are true at the same time:
- self-hosted runners already exist and are useful today
- heavy WebGL workloads still need dedicated GPU support that is not in the product yet
That means removing a browser flag such as --disable-gpu is not the real fix. The real fix is product and infrastructure support for GPU-enabled session containers.
What Self-Hosted Runners Support Today
Today, self-hosted runners are for teams that need:
- private-network execution
- local Docker capacity
- environment control
- outbound-only connectivity back to Certyn
That is the supported story today.
They are not yet the supported story for:
- heavy WebGL
- GPU-sensitive rendering validation
- hardware-accelerated browser execution inside session containers
What We Plan to Add
We do plan to add support for GPU-capable self-hosted execution.
That work is expected to include:
- Linux self-hosted runner support for GPU device passthrough
- GPU-capable agent images
- Validated browser launch and display configuration for GPU-backed runs
- Clear operator guidance for supported host setups
In other words, the plan is not "just flip GPU on in Chrome." The plan is to add proper end-to-end support.
What to Tell Customers Today
The honest message today is:
- self-hosted runners are supported
- heavy WebGL scenarios are not supported yet
- GPU-backed self-hosted support is planned
That is a much clearer promise than saying "WebGL sort of works" and letting teams discover the edge cases themselves.
Final Takeaway
Certyn supports self-hosted runners today.
Certyn does not support heavy WebGL scenarios today.
Certyn plans to add GPU-capable self-hosted support, but that should be communicated as planned work, not current capability.