Grok Build v0.2.117 Adds Custom TLS Support

If you use private CAs, internal proxies, or CI/CD jobs, this update is worth your time. I’d sum it up this way: v0.2.117 adds custom TLS certificate support and fixes a few connection problems that can break secure API calls in locked-down networks.

Here’s what changed in plain English:

• Custom TLS certificates now work, so I can trust internal CA chains and self-signed certs in private setups.
• TLS verification stays on, even when traffic goes through SSL inspection or internal gateways.
• Connection issues were fixed, including unknown issuer errors and some TLS handshake failures.
• Long-running jobs are less likely to stop, which matters in automation and headless runs.
• The update matters most for enterprise networks, staging systems, self-hosted services, and CI/CD pipelines.

A simple way to look at it: this release targets two main areas - certificate trust and runtime stability. If those two things affect your workflow, this version should move near the top of your upgrade list.

Bottom line: if your setup depends on private trust chains or locked-down network rules, this update can cut certificate workarounds while keeping encrypted connections in place.

Custom TLS certificate support

Grok Build v0.2.117 adds support for custom TLS certificates. That means the agent can trust internal CA chains in private PKI setups.

Put simply, Grok Build can now work with internal CA chains and self-signed certificates without relying on public trust workarounds.

Where custom certificates matter most

The main use cases are pretty clear:

For teams that use private PKI across internal services, the biggest upside is consistency. Grok Build can connect to internal endpoints without forcing teams to change certificate handling from one environment to another.

How this affects API workflows

This shows up most clearly in automated API calls and internal endpoint checks. When Grok Build runs through ACP in scripts or CI/CD pipelines, it can validate internal endpoints without running into certificate trust failures.

It also helps staging setups that mirror production security configurations. Teams can test with the same certificate setup used in controlled deployments.

Those certificate fixes matter even more alongside the reliability issues addressed in v0.2.117.

Bug fixes in v0.2.117

v0.2.117 also fixes connection handling, certificate validation, and runtime stability.

Reliability issues addressed

This release cuts down on unknown issuer errors and TLS handshake failures in internal CA and proxy setups. It also makes first-time connections steadier in strict staging networks.

Developer impact of the fixes

For restricted corporate networks, the main win is fewer trust-related interruptions during integration and long-running API jobs.

These fixes matter most when TLS trust and connection stability have a direct effect on automated API workflows.

Deployment impact: reliability and security

v0.2.117 makes Grok Build easier to deploy in restricted environments without turning off TLS verification. The big win here is simple: teams can use internal trust chains in locked-down setups and still keep secure connections working.

Security gains in controlled environments

This release lets Grok Build trust internal CA chains and TLS inspection proxies. That means connections can stay verified instead of failing because of untrusted-certificate errors. If traffic passes through a TLS inspection proxy or a private gateway, the app can authenticate that traffic with the organization’s own certificate setup rather than treating it as unsafe.

Because Grok Build ships as a prebuilt binary for macOS, Linux, and Windows ^[1][2], teams can set up TLS trust inside the app even when they can’t change the system root store.

Benefits for APIMart integrations

For APIMart deployments, this matters most when Grok Build runs through internal gateways or CI/CD automation. In practice, v0.2.117 removes a common deployment headache. If Grok Build connects to https://api.apimart.ai/v1 through an internal gateway that re-signs TLS traffic, custom certificate support keeps the connection verified without insecure fallbacks.

That also pairs neatly with GROK_DEPLOYMENT_KEY in headless CI/CD pipelines. Automated runs in staging or self-hosted setups can keep a secure trust boundary in place, even when they depend on internal proxies or self-signed certificates.

Who should upgrade and key takeaways

Building on the TLS and reliability fixes above, v0.2.117 matters most for teams with strict trust and automation requirements.

This release should be at the top of the list for teams running Grok Build in restricted or automated setups. That includes IT administrators managing private networks, internal CAs, enterprise setups, staging environments, or self-hosted infrastructure. DevOps engineers running Grok Build in headless CI/CD workflows should also move to this version, since the reliability fixes help reduce instability in deployment and automation flows.

Use the breakdown below to match upgrade priority to your deployment type.

Upgrade if your environment uses private CAs, internal proxies, or automated deployment workflows. If you're dealing with private CAs or internal proxies, upgrade now to preserve TLS verification and reduce automation failures.

FAQs

How do I add a custom TLS certificate in Grok Build?

The available documentation does not explain how to add a custom TLS certificate in Grok Build v0.2.117.

It does confirm support for enterprise, staging, and self-hosted environments. But it does not specify the command, config file, or environment variable required for this setup.

For the latest configuration syntax, check the official documentation or the user guide in the pager crate.

Will this update help if my company uses SSL inspection?

Yes. Grok Build v0.2.117 now supports custom TLS certificates, which is a big help in setups that use SSL inspection.

That means teams can run Grok Build in enterprise, staging, and self-hosted environments where traffic is intercepted or where a specific certificate chain needs to be trusted. The result is fewer connection errors and more steady performance across those setups.

Do I need to upgrade if my CI/CD jobs already work?

No - if your CI/CD pipelines already work, you do not need to upgrade.

You may want to upgrade if you need support for custom TLS certificates in enterprise, staging, or self-hosted setups, or if you want the bug fixes that improve reliability and security in automated workflows.