DEV Community: Ankur K

Stop Whitelisting Port 22: SSH into Private EC2 from GitHub Actions via AWS SSM 🔐

Ankur K — Sun, 20 Sep 2026 17:24:14 +0000

😩 The part of CI/CD nobody enjoys

You want a GitHub Actions job to rsync a build onto an EC2 box and restart a service. Simple, right?

Then reality shows up:

🔑 The key. You generate an SSH key pair, paste the private half into secrets.SSH_PRIVATE_KEY, and append the public half to ~/.ssh/authorized_keys on the instance. That key now lives forever. It never rotates. Anyone who can read repo secrets — or any action you uses: that decides to be clever — has shell on production.
🌍 Port 22. GitHub-hosted runners come from a huge, changing pool of egress IPs. So you either open 22/tcp to 0.0.0.0/0 (🙈), or you write a scheduled job that pulls GitHub's meta API and rewrites your security group ingress rules — dozens of CIDRs, churning weekly, on every instance you deploy to.
🏰 The bastion. The "proper" fix. Now you have an extra instance to patch, monitor, pay for, and whose own key you also have to manage. Congratulations, the problem has a second copy of itself.
🧟 The leftovers. A public IP on a box that has no business having one. A key on an ex-employee's laptop. A known_hosts prompt that hangs a job at 2am.

Every one of these is accepted as "just how deploys work." It isn't, anymore.

⚡ Enter AWS Systems Manager Session Manager

Session Manager flips the direction of the connection. 🔄

The SSM Agent on your instance makes an outbound HTTPS connection to AWS and holds it open. When you want in, you ask the SSM API for a session, and AWS brokers the two ends together over that existing channel.

Read that again, because everything good follows from it:

🚫 Zero inbound rules. Security group ingress can be completely empty. Port 22 closed. To everyone. Forever.
🕳️ No public IP, no bastion. Private subnet instances work identically. Behind a NAT gateway, or with no internet at all if you add the three VPC interface endpoints.
🪪 IAM is the auth layer. Access is an IAM policy, not a file on a disk. Revoke a role and access dies instantly — no hunting for authorized_keys entries.
📜 CloudTrail sees every session start, attributed to the identity that opened it.

And the underrated trick: the AWS-StartSSHSession document turns that broker into a raw byte tunnel, which OpenSSH will happily use as a ProxyCommand. Meaning SSH itself still runs — end-to-end encrypted, host keys and all — it just stops caring about routing.

Pair it with EC2 Instance Connect (SendSSHPublicKey) and the last piece falls over too: you push a freshly generated public key into instance metadata, where sshd picks it up for 60 seconds and then forgets it. 🔥 An SSH key with a one-minute shelf life. Nothing to rotate, nothing to leak.

That's the whole idea. The annoying part is the boilerplate: generate a key, push it, write a ProxyCommand block into ~/.ssh/config, get the host-key checking right, and tear it all down afterwards.

So I packaged it. 📦

🚀 The action

ankurk91/setup-ssh-over-ssm-action does the setup and the cleanup. It doesn't wrap ssh — it configures the runner, then gets out of your way.

name: Deploy

on:
  push:
    branches: [ main ]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7

      - uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: ${{ vars.AWS_IAM_ROLE_ARN }}
          aws-region: us-east-1

      - uses: ankurk91/setup-ssh-over-ssm-action@v1
        with:
          instance-id: ${{ vars.EC2_INSTANCE_ID }}
          os-user: ubuntu

      - run: ssh ssm-target 'uptime'

No secrets. No key. No security group rule. 🎉 OIDC gets short-lived AWS credentials, the action does the rest.

🧩 What it actually wrote

That middle step generates an ephemeral ed25519 key, pushes it via EC2 Instance Connect, and drops a fenced block at the top of ~/.ssh/config:

Host ssm-target
  HostName i-0123456789abcdef0
  User ubuntu
  Port 22
  IdentityFile "/home/runner/.ssh/ssm-ssm-target-i-0123456789abcdef0-9f3c1a2b"
  IdentitiesOnly yes
  StrictHostKeyChecking accept-new
  UserKnownHostsFile "/home/runner/.ssh/ssm-ssm-target-i-0123456789abcdef0-9f3c1a2b.known_hosts"
  ServerAliveInterval 30
  ControlMaster auto
  ControlPath "/home/runner/.ssh/ssm-9f3c1a2b.sock"
  ControlPersist 1h
  ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession \
    --parameters 'portNumber=%p' --region us-east-1 \
    --reason 'setup-ssh-over-ssm-action/18273645/1/9f3c1a2b'"
  Match all

Two details worth pointing at. The --reason stamp carries the workflow run id, so every tunnel is labelled in the Session Manager console and in CloudTrail — and the post step can find exactly its own sessions later. And Match all closes the stanza, because the block goes in first in the file and must not swallow any global directives you keep above your own Host lines.

Everything else is ordinary SSH config, which is the point: anything that speaks SSH just works, unmodified 🛠️

- run: rsync -az --delete ./build/ ssm-target:/var/www/app/current/
- run: scp ./config/production.env ssm-target:/srv/app/.env
- run: ssh ssm-target 'cd /srv/app && ./bin/migrate --no-interaction'
- run: ssh ssm-target 'sudo systemctl reload nginx'
- run: ansible-playbook -i inventory.yml site.yml   # ansible_host: ssm-target

Name the alias whatever reads well in your pipeline:

- uses: ankurk91/setup-ssh-over-ssm-action@v1
  with:
    instance-id: i-0123456789abcdef0
    host-alias: app-server
    os-user: ec2-user      # Amazon Linux

Bring your own key instead of the ephemeral one — it must have no passphrase, and it's the required route for hybrid mi- managed nodes, which EC2 Instance Connect doesn't support:

- uses: ankurk91/setup-ssh-over-ssm-action@v1
  with:
    instance-id: mi-0123456789abcdef0
    private-key: ${{ secrets.SSH_PRIVATE_KEY }}

🧹 And it cleans up after itself

A post step running on always() removes the config block, deletes the key material, closes the multiplexed master connection, and terminates the SSM sessions carrying this run's marker. Nothing survives the job. 🫧

✅ What you need

On the runner — AWS CLI v2 (recent enough to accept aws ssm start-session --reason) and the Session Manager plugin. Both are preinstalled on GitHub-hosted Ubuntu runners, so: nothing. On self-hosted, add install-aws-cli-action and install-session-manager-plugin-action.

On the instance — Linux, sshd running (the port can stay firewalled shut), SSM Agent ≥ 2.3.672.0, AmazonSSMManagedInstanceCore on the instance profile, and the ec2-instance-connect package (preinstalled on AL2023 standard and Ubuntu 20.04+).

On the runner role — ssm:StartSession, ssm:DescribeInstanceInformation, ssm:DescribeSessions, ssm:TerminateSession and ec2-instance-connect:SendSSHPublicKey. The ready-to-paste policy, plus the mistakes that cause most failures, are in docs/IAM.md. 👀 The big one: scoping ssm:TerminateSession with ${aws:username} silently does not work under OIDC federation — use a tag condition instead.

⚠️ Caveats

Sharp edges, up front:

🔇 No command-level audit. The tunnel is opaque to AWS, so session logging captures nothing readable and CloudTrail notes only that a session opened. If you need a record of what ran, reach for SSM Run Command instead.
🐌 It's a relay, not a pipe. Tens of MB move fine; a multi-gig artifact is miserable. Ship those through S3.
🔓 You still own sshd. The door moved, it didn't disappear — keep patching it.
⏱️ Keys expire after a minute. Only the first connection has to beat the clock (multiplexing carries the rest, for an hour of ControlPersist), so put the action right before the steps that use it. Long gaps in the pipeline? Pass your own private-key.
🏷️ Give overlapping jobs their own host-alias. Keys, sockets and known_hosts files are named per run, but the config block is keyed on the alias — so two jobs sharing an alias and a HOME on one self-hosted runner will tread on each other.
🐧 Linux only, runner and instance both.

Session cleanup, happily, is not on this list: each run stamps its tunnels with a unique --reason marker and the post step terminates only those, so concurrent jobs sharing a role, a runner and an instance never cut off each other. The long version of all of this lives in docs/Caveats.md.

🎬 Wrapping up

Long-lived SSH keys in CI secrets and IP-whitelisted port 22 are habits from before Session Manager existed. Swapping them out costs you one step in a workflow file and an IAM policy — and your deploy commands don't change at all.

🔗 Links

📦 The action: github.com/ankurk91/setup-ssh-over-ssm-action
🔐 IAM policies and gotchas
⚠️ Full caveats
📘 AWS: allow SSH connections through Session Manager
🔌 AWS: install the Session Manager plugin
🗝️ AWS API: SendSSHPublicKey
🧰 install-aws-cli-action · install-session-manager-plugin-action

⭐ If this saved you from writing another security-group-updating cron job, star the repo — it's the signal that tells me which parts to keep building, and it helps the next person find it instead of pasting a private key into a secret.

Issues and PRs welcome. 🙌 Closed port 22 already? Tell me how it went in the comments. 💬

🔐 A WireGuard GitHub Action That Actually Tells You When the Tunnel Is Dead

Ankur K — Tue, 08 Sep 2026 15:18:39 +0000

Your CI job needs to reach something private — a staging database in a VPC, an internal registry, a deploy target behind a firewall. The usual answers are bad: whitelist GitHub's entire runner IP range, or run a self-hosted runner just for network access.

Better idea: put the runner on your private network for the length of the job. 👉 ankurk91/wireguard-action

🧭 What is WireGuard?

A modern VPN protocol, and a small one — ~4,000 lines of code against OpenVPN's hundreds of thousands. It lives in the Linux kernel (mainline since 5.6), so it's fast. Its crypto isn't configurable, so there's nothing to downgrade. And config is just keys, SSH-style:

[Interface]
PrivateKey = <client private key>
Address = 10.0.0.2/32

[Peer]
PublicKey = <server public key>
AllowedIPs = 0.0.0.0/0
Endpoint = vpn.example.com:51820

That's the whole thing. Ephemeral, keyed, instant to bring up — a great fit for CI.

😤 Why another action?

I went looking and came away unhappy. Not naming names, but the same problems kept showing up: actions pinned to end-of-life node12/node16, docs that stop at a YAML snippet, huge bundled node_modules running as root, no cleanup step, and tunnel state dumped into job logs.

The big one: wg-quick up exits 0 even when your peer is unreachable. It creates the interface, adds the routes, reports success — and carries nothing. Your job then fails three steps later with a timeout that looks unrelated, and you burn an afternoon.

✨ Features

🩺 Verifies the handshake. After connecting, it sends real traffic and checks wg show for a completed handshake. Dead tunnel → the step fails here, with a message telling you to check Endpoint, keys, and UDP reachability. Skipped for split tunnels, where there's nothing meaningful to test.
🧼 Cleans up automatically. A post-if: always() step brings the interface down and deletes the config file on success, failure, or cancellation. No disconnect step to remember — and no private key left behind on a self-hosted runner.
📦 Zero dependencies. No node_modules, no bundled dist/. A ten-line node24 shim over readable, linted bash. You can audit the whole thing in five minutes — which matters for something running sudo on your runner.
🔍 Opt-in diagnostics. diagnostics: true prints wg show, addresses, routes, and your public IP before and after. Off by default, because that describes your network and job logs reach more people than your secrets do.
📚 Real docs. A README and a TROUBLESHOOTING.md written from failures I actually hit — including the two that bite everyone: GitHub runners have no IPv6 (strip IPv6 from your config or the tunnel won't start), and AllowedIPs = 0.0.0.0/0 routes the runner's own connection to GitHub through your VPN (if your VPN blocks that, the job hangs).

🚀 Getting started

1. Grab a client config from your WireGuard server — the whole wg0.conf.

2. Add it as a repository secret called WIREGUARD_CONFIG, pasting the entire file.

⚠️ Never commit the config or inline it — it holds your private key.

3. Add one step:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Connect to WireGuard VPN
        uses: ankurk91/wireguard-action@v1
        with:
          config: ${{ secrets.WIREGUARD_CONFIG }}

      # 👇 Everything below is routed through the VPN.
      - name: Talk to something private
        run: curl -sf http://10.0.0.50:8080/health

That's it — there is no disconnect step to add.

Input	Required	Default	Description
`config`	✅	—	Full config contents. Always from a secret.
`interface`	—	`wg0`	Written to `/etc/wireguard/<interface>.conf`.
`diagnostics`	—	`false`	Print tunnel state and routes to the log.

Requires an Ubuntu runner and an IPv4-only config.

🧪 Tested for real

Not "I ran it once." CI stands up a real linuxserver/wireguard server in Docker, in its own network namespace, and connects to it — a genuine tunnel, no mocks. It then asserts the interface is up, the config is mode 600, both ends agree on the client's public key, ICMP crosses the tunnel, and the byte counters are non-zero.

That runs 8× per commit: ubuntu-24.04 and ubuntu-26.04, on x86_64 and ARM, with diagnostics both on and off — plus shellcheck and checkbashisms, and a monthly schedule so runner-image drift is caught by CI instead of by you on a Friday. It's also in use in real projects; the handshake check exists because of one. 🔬 The test workflow.

⚡ Performance & 🛡️ Security

It runs before everything else in your job, so it stays light: no apt-get update on the happy path (it installs from the image's existing indexes and only refreshes if that fails), --no-install-recommends, skips the install entirely if wg-quick is present, and waits for the dpkg lock instead of flaking when unattended-upgrades holds it. The handshake check is bounded to 5s.

On the security side: the config is chmod 600 (asserted in CI), the interface input is validated against wg-quick's own character class so it can't escape /etc/wireguard, the key is removed on every exit path, diagnostics are opt-in, and the supply chain is empty. Pin @v1 — or a full SHA if your threat model asks for it.

🔗 Links

🧩 The action · README · Troubleshooting · Issues
🌍 WireGuard · whitepaper · wg-quick(8)
🏃 GitHub runner images · ⚖️ MIT

⭐ Star it if it saves you an afternoon.

Electron to Tauri: A 24-Hour Rewrite with Claude 🚀

Ankur K — Sun, 06 Sep 2026 09:48:46 +0000

TL;DR 📌

🕰️ Then: I built google-chat-electron by hand, over months, reading tutorial after tutorial.
⚡ Now: I rebuilt the whole thing as google-chat-tauri in less than 24 hours — and I did not write the code. Claude did.
🦀 Plot twist: I don't know Rust. Not a little — at all. The AI wrote every line of it.
📦 Result: a 3.3 MB Linux installer, against 66 MB for the Electron build of the same app. Same features. Real numbers, measured off both repos' release assets.
✅ Status: v1.0.1 — stable. Six releases in, and the pre-release label is off.

Let's dive in. 👇

The Electron Era: Months of Honest, Manual Labour 😅

A few years ago I wanted Google Chat in a real window — with a tray icon, an unread badge and native notifications — instead of a browser tab that disappears among thirty other browser tabs.

So I built it. In Electron. By hand.

And it took months. Not because Electron is bad, but because every single thing was a tutorial:

How do I make a tray icon that actually behaves?
How do I keep the app alive when the window closes?
How do I intercept a link and open it in the real browser?
How do I package a .deb? A .dmg? An installer for Windows?
Why does this work on my machine and nowhere else? 🙃

Every answer was a blog post, a GitHub issue thread, or a Stack Overflow reply from 2017 that almost applied. It shipped, people used it, and I was genuinely proud of it. It's no longer maintained — this is its replacement.

The Tauri Rewrite: One Evening, One Prompt Loop 🤖

I opened Claude Code and asked it to port the app to Tauri v2.

I did not open the Rust book. I did not read the Tauri docs. I described what the app should do, reviewed what came back, ran it on my actual laptop, and reported what broke.

Timeline:

Time	What happened
`15:42`	`git init`
`17:01`	Full Electron → Tauri v2 port committed
`17:25`	Desktop notifications working
< 24h later	`v0.0.1` tagged and released 🎉
+2 days	`v1.0.0`, then `v1.0.1` — stable ✅

72 commits. ~5,100 lines of Rust and JavaScript. Zero lines typed by me.

This is what people mean by vibe coding — and honestly, it felt less like programming and more like directing. My job became: describe the behaviour, test it on real hardware, and say "the tray icon doesn't come back on Wayland." The AI handled the rest.

⚠️ The honest caveat: AI wrote it, but a human ran it. Almost every real bug was a platform behaving differently from its own documentation — the kind of thing no model can find by reading docs. That part still needs a person with a laptop and some patience.

Tauri vs Electron: Why the Rewrite Was Worth It ⚖️

Here's the thing — Electron ships an entire Chromium browser with your app. Tauri doesn't. It uses the web engine your operating system already has: WebKitGTK on Linux, WKWebView on macOS, WebView2 on Windows.

	⚛️ Electron	🦀 Tauri v2
Browser engine	Ships its own Chromium	Uses the OS web engine
Linux installer size	66 MB (my old app)	3.3 MB (the same app) 🤯
Backend language	Node.js	Rust
Memory footprint	Heavy — it's a browser	Noticeably lighter
Startup	Boot a Chromium	Boot a native window
Security model	Opt-in hardening	Capability-based by default

Those two size numbers are the same app, same features, measured off the release assets of both repos. 20× smaller. 🤏

The rest of the bundles land in the same place: 1.9 MB for the Windows installer, 6.0 MB for the universal macOS .dmg. The one outlier is the Linux .AppImage at 85.7 MB — and it's the exception that proves the rule, because it's big precisely because it carries its own copy of the web engine for distributions that can't supply one.

The size difference is the headline, but the one you feel every day is startup and memory. You're not launching a second Chrome just to read messages from your team. The window opens like a native window, because it basically is one.

The trade-off? You inherit the OS web engine's quirks — and they are real. WebKitGTK renders its failed-load page as literally <html><body>%s</body></html> with no styling whatsoever, which on a dark window means black text on a black background. Chromium would never. More on that below. 🧪

What the App Actually Does ✨

This isn't a "hello world in a webview." It's a real desktop client:

🔴 Unread indicator — a dot on the tray icon, the count in the window title, and a badge on the macOS dock or Windows taskbar.
🔔 Desktop notifications — with sound. On Linux, clicking one brings the window back.
🗂️ Lives in the tray — closing the window hides it; the app keeps running and keeps notifying.
🪟 Remembers your window — size, position and maximised state come back where you left them.
1️⃣ Single instance — launching again just focuses the window you already have.
📋 Native menu bar — File, Edit, View, History, Preferences, Help, with zoom that persists between launches.
🚀 Starts how you like — launch at login, and/or start hidden in the tray on any launch.
⌨️ Keyboard shortcuts — Ctrl+F to search, Ctrl +/-/0 to zoom, Alt+←/Alt+→ to navigate, Alt+Home to get back to Chat, Ctrl+W to hide to tray.
🌐 Links open in your real browser — a Docs, Sheets or Calendar link opens where your extensions and logins already live. Only Chat stays in the window.
📎 Attachments download through your browser — it saves them the way it saves anything else.
🔐 Signs in normally — personal Google accounts and paid Workspace accounts, in any country.
🏢 SSO sign-in works too — Okta, Entra ID, Ping and friends.
📡 Handles a missing network gracefully — a readable offline page with a Try again button, and it reconnects on its own.
🧯 A way back from a wedged session — Help → Reset App Data signs you out, resets every preference and restarts clean.
🕵️ Logs you can paste into a public issue — paths and URLs go through a redactor first, so nothing in them names you.

No analytics. No auto-updater installing things behind your back — it just asks GitHub once or twice a day whether a newer release exists and tells you. You can turn that off. 🙌

Available for Linux (.deb + .AppImage), macOS (universal .dmg) and Windows (.exe).

The Bugs Reality Found 🐛

This is the part I'd actually read if someone else wrote this post. Every one of these was found by running the thing, not by reading docs — and every one of them is a platform doing something other than what it documents.

🏢 SSO / identity-provider sign-in

If your company signs you in through Okta, Entra ID or Ping, the flow redirects to your organisation's host — which the app can't know ahead of time, so it isn't on the short list of hosts allowed to stay in the window. The link opens in your browser and finishes the sign-in there, leaving the app still signed out. 🤦

The fix is pleasingly simple: Preferences → Temporarily Open Every Link in This Window. It explains what it's doing before it does anything, keeps every link inside the app for five minutes — long enough to get through any SSO flow — and then switches itself off again. No permanent footgun left enabled.

🚪 Sign Out that doesn't strand you

After signing out, Google sometimes answers a session-less visit with workspace.google.com — a marketing page — instead of the login form. And that page's own "Sign in" link did nothing, because the injected script intercepts cross-origin clicks on every page, the IPC permission only covered Google's Chat and Mail domains, and the resulting rejection was silently swallowed. Click → cancelled → dropped into the void. 🕳️

Now the window navigates itself when Rust can't be asked, and the app redirects off that marketing page to the real sign-in form (at most twice — a redirect loop is worse than a dead end). You should never have to wipe your data to sign back in.

📡 An offline screen you can actually read

Remember that WebKitGTK failed-load page? Black text, dark background, one unstyled line. The app rewrites that document into something readable with a Try again button.

Which, delightfully, could not simply reload — WebKit refuses to navigate its error page to the URL it's standing in for, and the page's opaque origin makes every IPC call fail with Origin header is not a valid URL. So the button aims at Chat's canonical URL instead, and in the background the app keeps probing the network and loads Chat by itself within about half a minute of your connection coming back. Usually before you even reach for the button. ✨

⌨️ Keyboard shortcuts that were pure decoration

Alt+Home was declared on the History menu and answered by absolutely nothing — GTK accelerators never reach the app while focus is inside the webview. Fine, route it through the injected script like every other shortcut.

Then Windows turned out to be worse. Tauri does build the accelerator table, and Windows does draw Ctrl+W next to the menu item — but the hook that would dispatch it only sees messages that reach the window's own message loop, and WebView2 has focus, always. Measured with synthetic keystrokes: Ctrl+W does nothing, clicking the exact same menu item works fine. The app now asks WebView2 for those keys directly. 🪟

🧊 A notification that froze the window

Showing a desktop notification on Linux measured, over 25 calls: median 48 ms, p90 86 ms, max 520 ms. Tauri runs synchronous commands on the main thread — which, on Wayland, is also the thread drawing your window's own close and minimise buttons. So a notification arriving made the titlebar stop responding, which reads as "the buttons are broken", not "the app is busy". Notifications now go out on a long-lived worker thread. 🧵

🤦 The bug I find funniest

The update checker couldn't see pre-releases. Which is a genuinely hilarious flaw in an app whose only releases were pre-releases. v0.0.1 could never have told you v0.0.2 existed.

The punchline is that GitHub's /releases/latest 404s for a repo that has only ever pre-released — it's documented as "the most recent non-prerelease release", so with nothing but pre-releases there is no latest at all, and the 404 is indistinguishable from having never shipped anything. Now that 1.0.0 is out, the rule flipped again: only stable releases are ever offered, so a beta never gets pushed at anyone. 🔁

🔒 Plus the boring-but-important stuff

Logs stopped leaking identity. Every path starts at your home directory, Google puts your email in sign-in URLs, an attachment link carries a bearer token, and a Chat URL's fragment names the open conversation. These files exist to be attached to public GitHub issues, so paths and URLs now go through a redactor on the way in.
The injected script got smaller off Chat. The full script only runs on Chat's own origin now; everywhere else gets the bare minimum it needs to hand a link to your browser.
CI got teeth. Five checks — fmt, clippy, cargo test, a syntax check and the injected script run against a stand-in page — gate the release workflow, so a tag on a commit that fails any of them produces no artifacts at all.

🚫 And one thing that simply cannot be built

Clicking a notification can't open that conversation. Chat's real notifications come through the service worker with no click handler the page can reach; the payload's tag identifies the sender, not the thread; and the document URL never moves off /app/home as you walk between conversations — confirmed in a stock browser, so it isn't a webview artefact. A click raises the window and stops there. Sometimes the answer is "no", and writing down why is worth more than another attempt. 🤷

Where Things Stand ✅

Let me be very clear about this part:

🎈 This is a fun project. It scratches an itch. It is not a startup.
🦀 I don't know Rust. If you open an issue about a borrow checker decision, the AI made it, not me.
✅ It's stable now. v1.0.1. Linux needs glibc 2.39+ (Ubuntu 24.04, Mint 22, Debian 13 and newer), macOS 15 Sequoia and newer, Windows 10 (1803+) or 11.
🧪 Linux is where it's been tested most. The macOS and Windows builds exist, CI produces them, and they still want real users on real machines. Both are unsigned, so the first launch needs a click through Gatekeeper or SmartScreen — the README spells out exactly which buttons.

If you use Google Chat on the desktop, try it and tell me what breaks. Every fix in the section above exists because something broke in real life — that's genuinely the most useful thing you can contribute. 🐛

# Debian, Ubuntu, Linux Mint
sudo apt install ./google-chat-tauri_*_linux-amd64.deb

(The leading ./ matters — without a path, apt goes looking for a package by that name in your repositories.)

The Takeaway 💭

Months of manual work, then a full rewrite in a different language, on a different framework, in under a day — by someone who can't write that language. Stable a few days later.

That's not a flex about me. It's a data point about where tooling is in 2026. And the releases since make the shape of it clearer: the hard part was never typing the code. It was knowing what the app should do and checking it against reality — the WebKit error page, the Google marketing redirect, the GTK accelerator that goes nowhere, the notification that freezes a titlebar. AI took the first job, instantly. The second one is still ours. 🤝

Every one of those findings is written down in the repo — what was measured, and on what — next to a file explaining which bits of code look wrong until you know why. That documentation isn't ceremony. It's the only thing stopping the next change from quietly undoing a fix that cost an afternoon. 📚

🔗 Links

🦀 Tauri version (new): https://github.com/ankurk91/google-chat-tauri
⚛️ Electron version (original, unmaintained): https://github.com/ankurk91/google-chat-electron
📥 Download the latest release: https://github.com/ankurk91/google-chat-tauri/releases/latest
🐛 Report an issue: https://github.com/ankurk91/google-chat-tauri/issues
📚 Tauri v2 docs: https://v2.tauri.app
🤖 Claude Code: https://claude.com/claude-code

Unofficial app. Not affiliated with, endorsed by, or sponsored by Google. "Google Chat" and the Chat logo are trademarks of Google LLC.

Have you migrated an Electron app to Tauri? Or vibe-coded something bigger than you expected? Drop it in the comments — I'd love to read about it. 👇

Deploy to EC2 from GitHub Actions without opening port 22

Ankur K — Sat, 05 Sep 2026 11:02:47 +0000

If you deploy to EC2 from GitHub Actions, the usual recipe is to put a private key in your repo secrets and SSH into the box. It works, but it means you are keeping a long-lived key around and leaving port 22 open to the internet (or to GitHub's very large IP range). AWS has a better answer for this: Systems Manager Run Command. The SSM Agent on your instance makes an outbound connection to AWS, and you send commands through the SSM API. There is no inbound port, no key to rotate, and every command is recorded in CloudTrail. Your instance can sit in a private subnet with no public IP at all and this still works.

I wanted to use this in my own pipelines. I looked around the marketplace and could not find a single action that did it well. Some were thin wrappers around aws ssm send-command that fired the command and never checked whether it actually succeeded. Some did poll, but swallowed the remote exit code, so a failed deploy showed up as a green build. Others hit the SSM output limit (roughly 24 KB) and truncated my logs right at the interesting part. A few were simply abandoned.

So I wrote one: ankurk91/aws-ssm-run-command-action.

SSM vs SSH

Both get the job done. Here is how they actually compare for CI/CD:

	SSM Run Command	SSH
Inbound port 22	Not needed	Required (or a bastion)
Public IP on the instance	Not needed	Usually needed
Credentials in CI	IAM role via OIDC, short-lived	Long-lived private key in secrets
Key rotation	Nothing to rotate	You own the whole rotation dance
Instance in a private subnet	Works (NAT or VPC endpoints)	Needs a bastion or VPN
Who can run what	IAM policies, scoped per instance or tag	`authorized_keys` on each box
Audit trail	CloudTrail + SSM command history	Whatever `auth.log` kept
Revoking access	Detach the IAM policy	Edit files on every server
Live output streaming	No, you poll and fetch	Yes
File copy (scp / rsync)	No	Yes
Server-side setup	SSM Agent + an IAM role	sshd + key distribution

SSM wins on everything that matters for security and access control. SSH keeps two real advantages: live output streaming and file transfer. For a deploy script I have not missed either. The full log lands in S3 anyway, and it is usually better to have the server pull its build artifacts from S3 or a registry than to push them over scp from a runner.

Using the action

You need three things on the AWS side:

The SSM Agent on the instance. Amazon Linux and the official Ubuntu AMIs already ship with it.
An IAM role attached to the instance with the AmazonSSMManagedInstanceCore managed policy.
A private S3 bucket for logs. This is how the action gets around the 24 KB output limit. Add a lifecycle rule to delete old objects and forget about it.

Then the workflow:

name: Deploy

on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v6
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      - name: Run commands on EC2
        uses: ankurk91/aws-ssm-run-command-action@v1
        with:
          ec2_instance_id: ${{ vars.EC2_INSTANCE_ID }}
          run_as_user: ubuntu
          log_bucket_name: ${{ vars.LOG_BUCKET_NAME }}
          commands: |
            set -e
            cd /var/www/app
            git pull --ff-only
            npm ci
            npx prisma migrate deploy
            npm run build
            pm2 reload ecosystem.config.js --update-env

That is the whole thing. No secrets other than the AWS role, no port 22.

A few notes from using this in production:

Start your script with set -e. Without it the shell keeps going after a failed command and reports success.
The action exposes a command-exit-code output, so you can branch on it if you need to.
execution_timeout defaults to one hour. Lower it for a normal deploy so a hung command does not sit there burning runner minutes.
Full output lands in your S3 bucket, so nothing gets cut off.

The pipeline itself only needs ssm:SendCommand, ssm:ListCommandInvocations and ssm:GetCommandInvocation. The full policy is in the repo.

Bonus: port forwarding through SSM

Run Command is for firing off a script on the server. Sometimes you want a network connection instead. In the deploy above, prisma migrate deploy runs on the EC2 instance, which is fine. But you may prefer to run migrations from the runner, so that a bad migration fails the pipeline before any new code goes out.

That needs the runner to reach your database, and your database is almost certainly in a private subnet. Session Manager port forwarding solves it, and enkhjile/aws-ssm-remote-port-forwarding-action wraps it up nicely. It closes the session in its post step, so there is nothing for you to clean up.

      - name: Open a tunnel to RDS
        uses: enkhjile/aws-ssm-remote-port-forwarding-action@v1
        with:
          target: ${{ vars.EC2_INSTANCE_ID }}
          host: my-db.abc123.ap-south-1.rds.amazonaws.com
          port: 5432
          local-port: 5432

      - name: Run Prisma migrations through the tunnel
        run: |
          npm ci
          npx prisma migrate deploy
        env:
          DATABASE_URL: postgresql://${{ secrets.DB_USER }}:${{ secrets.DB_PASSWORD }}@127.0.0.1:5432/app?schema=public

Prisma just sees a database on localhost. Your EC2 instance is the jump host, but you never log into it, and neither the instance nor the RDS security group needs an inbound rule from the internet.

Wrapping up

If you are still shipping a private key to GitHub secrets to deploy to EC2, SSM is worth an afternoon of your time. You delete the key, close the port, and get an audit log for free.

Links:

The action: github.com/ankurk91/aws-ssm-run-command-action
Port forwarding action: github.com/enkhjile/aws-ssm-remote-port-forwarding-action

AWS docs:

If you try the action and something is missing, open an issue on the repo. Stars are appreciated too.

Putting GitHub Actions runners on your private network with NetBird

Ankur K — Fri, 04 Sep 2026 11:05:45 +0000

Sooner or later a CI job needs to reach something that is not on the public internet. A staging database, an internal
container registry, a deploy target sitting behind a firewall, an integration test suite that talks to a service you
have no intention of exposing.

The usual answers are not great. You can allowlist GitHub's egress ranges, which are enormous, change regularly, and
effectively mean "allow anyone's CI job". You can move to self-hosted runners and inherit the maintenance. Or you can
run some VPN client in the job and hope the setup survives contact with a fresh container every time.

I went with the third option, and ended up writing the action I wanted:
ankurk91/netbird-action.

🔐 A short word on NetBird

NetBird is an overlay network built on WireGuard. Every machine you enrol becomes a peer with a
stable address in the 100.64.0.0/10 range, and peers talk to each other directly. There is a control plane that
distributes configuration and access policy, and helps two peers find each other through NAT, but it does not sit in
the data path once a tunnel is up.

That last part is the real difference from a traditional VPN. A classic setup is hub and spoke: a concentrator with a
public IP and an open port, and everything routed through it. That box is a bottleneck, a single point of failure, and
the one thing on your perimeter that absolutely must never be misconfigured. It also tends to hand out access by
subnet, so being on the VPN means being on the network.

NetBird works the other way around:

No inbound port anywhere. Peers dial out to the control plane. Nothing on your side needs a public listener.
Direct tunnels. Traffic goes peer to peer over WireGuard, so latency is whatever the two machines' path is, not a round trip through a concentrator in another region.
Access by identity, not by subnet. Peers are grouped, and policies say which group can reach which. A runner joins a group that can reach the staging database and nothing else.
Setup keys. Machines enrol non-interactively with a key, which is exactly what CI needs. Mark the key ephemeral and the peer drops out of the dashboard on its own once the job is gone, so you are not left deleting dead runners by hand.

There is a free tier that covers a small team, and you can self-host the whole control plane if you would rather.

🧩 Why another action

I looked for an existing one first. What I found had not been touched in a long time, installed client versions that
were several releases behind, and was careless in the one place I could not afford carelessness: something that holds a
credential to my entire private network.

The behaviour that bothered me most was subtler than that, though. Most of them treat "the client reported success" as
"the job can now use the network". Those are not the same moment. A peer registers well before it can actually carry
traffic, and private DNS settles later still. If the next step in your job immediately reaches an internal service, you
get a pipeline that passes four times and fails the fifth, with nothing useful in the log.

So this action's whole job is to not hand control back until the network is genuinely usable — and to say clearly what
was missing when it cannot.

🚀 Getting started

The only required input is the setup key. Create one in the dashboard under Settings → Setup Keys, turn on
Ephemeral Peers, give it a group your access policies already allow, and store it as a repository secret.

name: Integration tests

on:
  push:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v5

      - name: Connect to the NetBird network
        id: netbird
        uses: ankurk91/netbird-action@v2
        with:
          setup-key: ${{ secrets.NETBIRD_SETUP_KEY }}

      - name: Run tests against the internal API
        run: |
          echo "this runner is ${{ steps.netbird.outputs.netbird-ip }} on the network"
          npm run test:integration
        env:
          API_URL: http://internal-api.netbird.cloud

From that point the runner is a peer. It can reach your other peers by their NetBird address, or by name under
.netbird.cloud. There is no disconnect step to add on a hosted runner — the machine is destroyed when the job ends,
and an ephemeral key takes care of the dashboard entry.

Self-hosting the control plane only changes one input:

      - uses: ankurk91/netbird-action@v2
        with:
          setup-key: ${{ secrets.NETBIRD_SETUP_KEY }}
          management-url: https://netbird.example.com:443
          version: 0.78.1

Pinning version is worth doing for anything you care about reproducing. Left at latest, the action installs
whatever the newest client release is on the day the job runs.

🌐 Connected is not the same as ready

This is the part I care about most, so it gets its own section.

Joining the network and being able to resolve your private hostnames are two different milestones, and the gap between
them is where flaky pipelines live. If the next step in your job reaches a service by name, list those names and the
action waits until they actually work before it hands over:

      - uses: ankurk91/netbird-action@v2
        with:
          setup-key: ${{ secrets.NETBIRD_SETUP_KEY }}
          dns-hostnames: |
            postgres.netbird.cloud
            internal-api.netbird.cloud

There is a second failure this closes, and it is the nastier one. Plenty of names exist in both public DNS and your
private zone. Public DNS can answer first, and then your "internal" call quietly leaves the mesh and talks to the far
side of the internet instead. Nothing errors. It surfaces an hour later as a confusing 403 from an API that was
supposed to be internal.

So by default a name only counts as ready once it points inside your network. If it answers with a public address,
the action keeps waiting, and on timeout it tells you which name resolved to what. For a name that is genuinely
supposed to answer publicly — one reached through an exit node, typically — turn the check off:

          dns-hostnames: api.example.com
          dns-require-private: false

🛰️ Routing through an exit node

An exit node is a peer in your network that other peers can route their internet traffic through. Select one, and the
runner's outbound traffic leaves from that peer's public IP instead of GitHub's.

That solves a problem plenty of teams run into: a third-party API, a payment gateway, a partner's SFTP server or a
cloud provider's console that only accepts requests from an allowlisted IP. GitHub-hosted runners draw from a huge,
shifting pool of addresses, so there is nothing useful to allowlist. Route the job through an exit node with a static
IP and you have one address to hand over.

      - name: Connect through the exit node
        uses: ankurk91/netbird-action@v2
        with:
          setup-key: ${{ secrets.NETBIRD_SETUP_KEY }}
          exit-node: ${{ vars.NETBIRD_EXIT_NODE_ID }}

      - name: Call the partner API from a known IP
        run: ./scripts/sync-partner-data.sh

exit-node takes the network ID as it appears in your dashboard. The route has to be distributed to a group your setup
key assigns to the runner, otherwise the peer never receives it — the action waits for it, selects it, and says so
plainly if it never arrived.

⚠️ One caveat worth internalising: an exit node carries 0.0.0.0/0, and that includes the runner's own connection back
to GitHub. If the exit node cannot reach GitHub, the runner stops reporting and the job sits there until it times out.
Try it on a workflow_dispatch run before you put it behind a required check.

Leave exit-node unset and none of this applies. The runner joins the network and keeps its own egress.

🧹 Self-hosted runners

Hosted runners are disposable, so there is nothing to clean up. Self-hosted ones are the exception: the machine
outlives the job, and without teardown the next build on that runner inherits a network it never asked to join.

      - uses: ankurk91/netbird-action@v2
        with:
          setup-key: ${{ secrets.NETBIRD_SETUP_KEY }}
          cleanup: true

That deregisters the peer and undoes the install when the job ends, on success or failure. It is off by default so
hosted runners do not pay for a teardown nobody needed.

💡 Where this is useful

Deploying to private infrastructure. SSH to a host with no public address, run migrations against a database in a private subnet, push to an internal registry.
Integration tests against real internal services. Rather than mocking the internal API, or exposing it.
A stable egress IP for allowlisted third parties. The exit node case above.
Hybrid setups. A runner in one cloud reaching services in another, without VPC peering or a site-to-site tunnel.
Hardware you cannot move. Anything already on your NetBird network is reachable from CI, lab machines included.

🔗 Links

Action repository: github.com/ankurk91/netbird-action
Marketplace listing: Setup NetBird
Troubleshooting guide
How it works, if you want the reasoning behind any of the above
NetBird documentation

It is MIT licensed, Linux only, and tested against real runs on every push. If you hit something the troubleshooting
guide does not cover, open an issue. ⭐