DEV Community: Ankur K

I Rewrote My Electron App in Tauri — and Claude Did 100% of the Work in Under 24 Hours 🚀

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 MB Linux installer instead of a bundled Chromium.
🧪 Status: pre-release. Fun project. Stable version coming after real-world testing.

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.

The Tauri Rewrite: One Evening, One Prompt Loop 🤖

Last week 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 🎉

38 commits. ~3,600 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	~80–100 MB	~3 MB 🤯
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

The size difference is the headline number, 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 — WebKitGTK on Linux behaves differently from Chromium, and you find that out the hard way. Which is exactly what the testing phase is for. 🧪

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.
🚀 Launch at login — optional, plus "start hidden in the tray."
⌨️ Keyboard shortcuts — Ctrl+F to search, Ctrl +/-/0 to zoom, Alt+←/Alt+→ to navigate, 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.
🔐 Signs in normally — personal Google accounts and paid Workspace accounts, in any country.
📡 Says when it can't reach Chat — instead of a blank web engine error page.
🧯 A way back from a wedged session — Help → Reset App Data signs you out, resets every preference and restarts clean.

No analytics. No auto-updater installing things behind your back — it just asks GitHub once 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).

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 still pre-release. v0.0.1. Linux is where it's been tested most; macOS and Windows builds exist and need real users on real machines.
✅ A stable release is coming once it's been properly tested in the wild.

If you use Google Chat on the desktop and you're feeling brave, try it and tell me what breaks. That's genuinely the most useful thing right now. 🐛

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.

That's not a flex about me. It's a data point about where tooling is in 2026. The hard part of this project was never typing the code — it was knowing what the app should do and checking it against reality. AI took the first job. The second one is still ours. 🤝

🔗 Links

🦀 Tauri version (new): https://github.com/ankurk91/google-chat-tauri
⚛️ Electron version (original): https://github.com/ankurk91/google-chat-electron
📥 Download the pre-release: https://github.com/ankurk91/google-chat-tauri/releases
🐛 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 management service that
distributes configuration and an access policy, plus a signal service that helps two peers find each other through NAT,
but neither of them sits 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 management and signal services. 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 is removed automatically once the job ends, so your dashboard does not slowly fill with dead runners.

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, pinned client versions that were
several releases behind, and cut corners I was not comfortable with in something that holds a credential to my network.

The two that bothered me most: passing the setup key as a --setup-key command line flag, where it lands in the
process list for anything else on the machine to read, and treating netbird up returning as "connected". It is not.
That command returns once the daemon has accepted the login, which is earlier than the peer being able to carry
traffic. The signal connection and the network map arrive after. If the next step in your job immediately curls an
internal service, you get a flaky pipeline and no idea why.

So the action waits for Management: Connected and Signal: Connected before handing control back, writes the key to
a temporary file instead of argv, and fails with an actionable message instead of hanging.

Usage

The only required input is the setup key. Create one in the dashboard under Settings -> Setup Keys, turn on
Ephemeral, give it a group your 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@v7

      - name: Connect to the NetBird network
        id: netbird
        uses: ankurk91/netbird-action@v1
        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 other peers by their NetBird IP, or by name under
.netbird.cloud if you have a nameserver group covering it. There is no disconnect step to add: with an ephemeral key
the peer disappears on its own once the runner is destroyed.

Self-hosting the control plane only changes one input:

      - uses: ankurk91/netbird-action@v1
        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.

The exit node

This is the optional feature I get the most questions about, so it is worth explaining properly.

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 have 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 give them.

      - name: Connect through the exit node
        uses: ankurk91/netbird-action@v1
        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 the dashboard and netbird routes ls show it. The route has to be distributed to
a group the setup key assigns to the runner, otherwise the peer never sees it. The action waits for the route to
arrive, then selects it, and tells you plainly if it never showed up rather than failing on the next step.

One thing to keep in mind, and the README says this in a warning box too: an exit node carries 0.0.0.0/0. That
includes the runner's connection back to GitHub. If the exit node cannot reach GitHub, the job stops reporting and sits
there until it times out. Test it on a workflow_dispatch run before you put it in a required check.

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

Where this is useful

Deploying to private infrastructure. SSH to a host that has 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.
Self-hosted runners in a hybrid setup. A runner in one cloud reaching services in another, without peering or a site-to-site tunnel.
Reaching a colleague's or a lab machine. Anything already on your NetBird network is reachable from CI, which includes hardware you cannot move.

Details worth knowing

A few decisions in the action that are not obvious from the input list:

The setup key is written to a temporary file and passed with --setup-key-file, never on the command line, and it is masked in the log even if someone passes it from vars by mistake.
The install uses the release binary rather than the apt package, which avoids adding a repository and an apt-get update, and covers the -arm runners on the same path.
A github-token is sent only when you pin a version, because that path resolves the tag through the GitHub API and hosted runners share egress addresses. latest reads NetBird's CDN and gains nothing from a token, so it never sees one.
diagnostics is off by default. Turned on it prints netbird status -d, the routes and the public IP before and after connecting, which is exactly what you want when a connection fails and exactly what you do not want sitting in a job log the rest of the time. Failures print an anonymised status either way.