Why is my Bolt app not opening?
If your published bolt.host address shows “This site can't provide a secure connection”, “<your-site>.bolt.host sent an invalid response” or ERR_SSL_PROTOCOL_ERROR, Bolt says your network or internet provider may be blocking the address. The error alone does not establish that publishing failed. Start by comparing the same published URL in the same browser across networks you are authorized to use. Bolt publishing issues.
This guide covers that published-site connection problem. If you can open the page but the app is blank or fails when you use it, continue with Bolt deployment issues: check the production build. If the error happens inside the Bolt editor, use Bolt “Something went wrong”: find the real error.
Confirm the published address and access setting
Open your project's Publish menu and check the site's address. Use that published address for the comparison, rather than the editor or preview URL. Bolt's hosting guide documents the published link and the site's visibility in this menu. Bolt Publish guide.
Read the visibility setting without changing it. A private site is available to its team, invited viewers and users whose email addresses belong to a configured trusted domain. If you reach an access or sign-in screen, ask the project owner to confirm that your account has the intended access. Keep the site private if that is its intended setting; making production public is not a diagnostic step. Bolt Publish guide.
Check the Bolt status page before changing the project. If a reported incident covers your problem, retest after it is resolved, as Bolt's publishing guidance recommends. A status page is a service-level check, not a test of your particular URL.
Compare the same URL without changing the app
Bolt recommends trying mobile data, another Wi-Fi network or a phone hotspot for this error. Our comparison below holds the browser and URL constant so the result is easier to interpret. It is a diagnosis order based on the vendor's network test, not a report of a test we ran on a customer site.
- On the affected device, record the exact published URL, browser, error text, time and whether a VPN is active. Reload that URL and note whether you get a browser connection error, a site access screen or the app itself.
- Keep the same device, browser profile, account state and VPN state. If the VPN state changes automatically, record that difference as a limitation. If permitted, connect that device to another authorized network, such as your own phone's hotspot, and open the same URL again. Keep the path identical too.
- Record the result before editing code, republishing or changing access settings. If permitted, repeat on the original network to see whether the difference persists.
Keep browser TLS checks, security software and organization controls enabled. Do not turn off a required VPN or bypass a work or school network policy. If a managed connection prevents a meaningful comparison, ask your administrator to perform or authorize the check. Record that limitation instead of treating the test as conclusive.
Testing on a different phone can still provide a useful observation, but it changes the device and browser as well as the network. Label it that way. Chrome's connection guidance lists device, browser, network and website causes; a changed result does not identify the responsible component by itself. Chrome connection guidance.
Read the comparison, then choose the next check
This is a decision matrix, not measured results. The network branch follows Bolt's publishing troubleshooting; the private-access branch follows its Publish guide. The limits on what to conclude are our interpretation of those sources and Chrome's list of possible causes.
| Observation at the same published URL | What it supports | Next action |
|---|---|---|
| The same browser shows the secure-connection error on the original network, but opens the app on another authorized network | A network-dependent difference. It does not identify the exact filter or prove every app feature works. | Give your network administrator or internet provider the exact hostname and comparison. Ask them to investigate filtering for that site. |
| The same secure-connection error appears on every authorized network you can test | You have not isolated an original-network-only problem. A shared device or managed connection may still affect the comparison. | Check Bolt's status and contact Bolt support with the site URL, exact error and observations. State any test limitations. |
| The URL reaches a private-site access screen | Treat this as an access question before a network-blocking diagnosis. Bolt restricts private sites to their team, invited viewers and users with a configured trusted email domain. | Have the project owner verify the intended viewer access. Do not switch the site to public to test it. |
| The browser opens the page, but the app is blank or an action fails | The observed problem has moved beyond the initial browser secure-connection screen. It may still involve a failed app request. | Follow the production-build guide and record the app error separately. |
| A different device works, but you could not hold the browser and account constant | The comparison changed more than the network. | Record the difference and ask for a controlled check; do not label the original network as proven blocked. |
Sources for the matrix: Bolt publishing issues, Bolt Publish guide, and Chrome connection guidance.
For a work or school network, send the evidence to the administrator. For your own connection, ask your provider to check its protection settings for the exact site address. Any exception should be reviewed by whoever manages that protection. This workflow does not require trusting all bolt.host sites or weakening browser security.
If the error persists on all tested networks, Bolt's documented next step is to contact support and include the site's URL. Add the exact error and the comparison details above. Remove passwords, tokens and private data from screenshots or copied output. Bolt publishing issues.
Check Bolt's publishing result before trying another update
If you own the project, open Code view with the code icon, then inspect Publish Output in the bottom panel for the publishing result. That tab is for publishing output; the Bolt tab covers preview and project activity. For this check, use Chrome or another Chromium browser on a laptop or desktop. You do not need to run a command or edit a file. Bolt Code view.
A build failure belongs in the deployment guide. Bolt builds the project when it publishes and then looks for the output folder. A browser secure-connection error on an already published address is a different observation from a failed publish build. Bolt publishing issues.
Project edits do not automatically reach the live site. If a separately diagnosed problem requires a change, the documented route for an existing site is Publish > Update. Once that update finishes, reopen the published URL and repeat the same read-only check. Preserve the intended visibility. A workspace preview or a successful build alone is not the published-URL check. Bolt Publish guide.
If the failing address is your own custom domain
Keep the custom-domain result separate from the bolt.host result. For a custom domain you own, the free custom-domain SSL checker checks public DNS and certificate information for the entered name and its www counterpart. A proxy can limit what it sees; it cannot establish the origin certificate behind Cloudflare's proxy. Checker scope.
Use it only for your own custom domain. This is not a request to scan arbitrary bolt.host addresses. A server-side domain check cannot reproduce your browser's network path, and it does not verify application code, sign-in permissions or whether a private Bolt site should admit you.
Need help with the production problem?
Request a Production Readiness Audit. Include the failing URL, the exact error and your network comparison, with secrets removed.
How we checked this
This guide uses Bolt's publishing troubleshooting, Publish and Code view documentation, Google's Chrome connection guidance, and Enviera's checker scope, read on 1 November 2026. The links appear below. Bolt's status page was also read on that date; check it again when diagnosing your own issue.
The network comparison is our diagnosis order based on vendor documentation. We did not reproduce a blocked-network incident, test a private Bolt site, publish an app or verify a customer's fix. The matrix describes possible observations and next checks, not test results or a guarantee.
Sources
All sources read on 1 November 2026. Publication/update dates were not displayed in the text read.
- Bolt Support, Publishing issues: secure-connection messages, network comparison, status check, support escalation and publish build.
- Bolt Support, Publish your project to a live website: published addresses, private access and Publish > Update.
- Bolt Support, Use Code view: Publish Output, panel tabs and desktop Chromium guidance.
- Bolt, Status: current service-status reference.
- Google Chrome Help, Fix connection and loading errors in Chrome: device, browser, network and website causes.
- Enviera, Custom-domain SSL checker: DNS, certificate and proxy limits.
- Enviera, Prototype to production: existing Production Readiness Audit.