Skip to main content
Question

blocks-cli ships an expired localhost certificate (expired 2021) — breaks Development mode in the desktop app

  • August 22, 2026
  • 3 replies
  • 118 views
vino
Forum|alt.badge.img+2

Hi,

The certificate that `block run` serves — `node_modules/@airtable/blocks-cli/keys/server.crt` — expired on 18 May 2021. Screenshot from Keychain Access attached.

Because of this, Development mode doesn't work in the Airtable desktop app on macOS. The app won't accept an expired cert and gives you no way to override it, so you get "Connection error. Please check if your local block is running" even with `block run` clearly listening. Trusting the cert at the system level doesn't help — expiry wins over trust settings.

The workaround is to develop in Safari instead of the desktop app, since the browser lets you click through the warning.

Two questions:
- Could the certificate be regenerated in the next CLI release, with a longer validity this time?
- Is there any supported way to point `block run` at my own cert (mkcert, for instance)?

Setup: macOS Apple Silicon, Node v20.20.2, blocks-cli 3.0.1, @airtable/blocks interface-alpha.

Thanks

 

3 replies

anthonyXRay
Forum|alt.badge.img+6
  • anthonyXRay
  • Participating Frequently
  • August 26, 2026

This is kind of a known pain point.  It has to do with the bundled server .crt in blocks-cli that expired in 2021 and has never been refreshed.  So there is no supported way to swap in your own cert (mkcert or otherwise) at the moment.  block run doesn’t expose a flag for a custom cert/key path.

Safari is the standard workaround since browsers let you click through the expired-cert warning; the desktop app just hard-fails instead of prompting.  A workaround some people try is patching the generated cert directly in node_modules with a self-signed one from mkcert and manually trusting it, but that isn’t persistent across reinstalls and is not supported officially.

Probably a good idea to go ahead and file both of those asks as separate feedback through the Airtable support form.

Anthony at XRay
    Forum|alt.badge.img
    • arhamblake38
    • New Participant
    • August 28, 2026

    That sounds like a legitimate development-environment issue if blocks-cli is shipping a localhost certificate that expired in 2021. Even though the certificate is for localhost, modern clients can still reject it and prevent the desktop app's Development mode from establishing a connection.

    I’d check whether the certificate is actually bundled with the current blocks-cli release or being pulled from an older local installation/cache. If it is included in the package, replacing it with a newly generated development certificate would be the proper long-term fix. It would also be useful to verify whether the desktop app allows a development-only self-signed certificate or has a documented way to trust the local certificate.

    For a bug report, including the exact blocks-cli version, operating system, certificate expiry date, and the desktop-app error would make the issue much easier to reproduce. Hopefully this can be corrected in the next release rather than requiring developers to work around an expired certificate manually.

    For a quick break while waiting on a fix, adoptmevalues.de can also be worth checking out.

      Forum|alt.badge.img
      • CarlAndrew
      • New Participant
      • August 29, 2026

      This sounds like a frustrating issue, especially when an expired localhost certificate prevents development mode from working properly in the desktop app. Checking whether the certificate is being bundled with the Blocks CLI and replacing or renewing it should help resolve the problem. It would also be useful for Airtable to provide an updated CLI release so developers don’t have to work around an expired certificate manually.

        Terms & ConditionsAccessibility statement