20+ years of coding experience across video games, logistics, finance, real estate, and legal/law industries. I'm a versatile, abstract-thinking solver of problems across many domains and disciplines
That bump in speed with updates and killing off zombie processes are great housekeeping things to address early (like you did)!
I'm absolutely stoked for you to hear your talks are happening! I'm looking forward to hearing how it goes.
You have a unique built-in performance check by building, and using, your platform from your phone. It's incredibly frustrating using tools and platforms that're clearly not tested for not-top-end hardware.
You nailed it with the word "housekeeping." It’s so tempting to just chase the shiny new features, but you and I both know that a platform is only as good as its ability to clean up after itself and not bankrupt the founder.
And you are 100% right about the hardware constraint. Building and testing on this $150 phone is my ultimate reality check. If a tool is too heavy or poorly optimized for my device, I know it will be terrible for students and indie hackers with similar setups. It forces me to write lean, efficient code.
Thank you for always reading the details and for the incredible support. I will definitely keep you posted on how the IIT Madras talks go! 🐯☁️
The zombie sandbox fix stood out to me more than the 3 second reload. Passing lifecycle onTimeout kill at creation, plus the hourly pg_cron cleanup with a TTL and a 10 minute grace period, is the kind of guardrail that stops a forgotten environment from turning into a surprise bill. The surgical update is smart too: polling with ETag caching so the watch does not hammer the API, then fetching and resetting in the existing MicroVM while keeping the same URL. Building and testing all of this on a phone in Termux makes the performance discipline real. How did you settle on the 10 minute grace period, and did the MD5 polling replace fs.watch for the GitHub watch path as well, or only for local file changes?
Good morning! Thank you for such a sharp, detailed read of the article. It means a lot when senior devs catch the nuance in the unsexy stuff. 🙏
To answer your questions:
1. The 10-Minute Grace Period:
This was a calculated balance between user safety and cost control. E2B sandbox teardown isn't always instantaneous, and there can be slight clock drift or network latency between the client, Supabase, and the E2B control plane. A 10-minute buffer ensures that if a user's session just expired but they are actively saving their last changes, we don't aggressively nuke their work mid-operation. However, 10 minutes is short enough that even in a worst-case "rogue process" scenario, it won't trigger a meaningful billing spike. It’s the sweet spot.
2. MD5 Polling vs. ETag Polling:
Great catch! They serve two different paths:
Local File Changes (hyna-stage watch): I completely replaced fs.watch with MD5 hash-based polling. fs.watch is notoriously flaky, especially in Termux/Deno environments, and would sometimes trigger infinite loops or miss events. MD5 polling is bulletproof and cross-platform.
GitHub Watch (hyna-stage watch --github): For this, we don't touch the local file system watcher at all. Instead, the CLI polls the GitHub REST API for new commit SHAs using ETag caching. This ensures we get instant updates without hammering the GitHub API or triggering rate limits.
Building on a $150 phone forces you to be ruthless about performance and reliability. There is no room for flaky watchers or memory leaks!
Thanks again for the fantastic questions. Keep an eye out, v3.0.0 is right around the corner! 🐯☁️⚡
JavaScript enthusiast with a growing passion for Python. I love exploring the world of programming, experimenting with code, and discovering new ways to turn ideas into reality.
JavaScript enthusiast with a growing passion for Python. I love exploring the world of programming, experimenting with code, and discovering new ways to turn ideas into reality.
@effessdev bro!!
What?
Bro what do you think
Good! 👍
Just? Good hah
Not just "Good" but "Good" with an exclamation mark and a thumbs up emoji!
That bump in speed with updates and killing off zombie processes are great housekeeping things to address early (like you did)!
I'm absolutely stoked for you to hear your talks are happening! I'm looking forward to hearing how it goes.
You have a unique built-in performance check by building, and using, your platform from your phone. It's incredibly frustrating using tools and platforms that're clearly not tested for not-top-end hardware.
Thank you, David! 🙏
You nailed it with the word "housekeeping." It’s so tempting to just chase the shiny new features, but you and I both know that a platform is only as good as its ability to clean up after itself and not bankrupt the founder.
And you are 100% right about the hardware constraint. Building and testing on this $150 phone is my ultimate reality check. If a tool is too heavy or poorly optimized for my device, I know it will be terrible for students and indie hackers with similar setups. It forces me to write lean, efficient code.
Thank you for always reading the details and for the incredible support. I will definitely keep you posted on how the IIT Madras talks go! 🐯☁️
The zombie sandbox fix stood out to me more than the 3 second reload. Passing lifecycle onTimeout kill at creation, plus the hourly pg_cron cleanup with a TTL and a 10 minute grace period, is the kind of guardrail that stops a forgotten environment from turning into a surprise bill. The surgical update is smart too: polling with ETag caching so the watch does not hammer the API, then fetching and resetting in the existing MicroVM while keeping the same URL. Building and testing all of this on a phone in Termux makes the performance discipline real. How did you settle on the 10 minute grace period, and did the MD5 polling replace fs.watch for the GitHub watch path as well, or only for local file changes?
Good morning! Thank you for such a sharp, detailed read of the article. It means a lot when senior devs catch the nuance in the unsexy stuff. 🙏
To answer your questions:
1. The 10-Minute Grace Period:
This was a calculated balance between user safety and cost control. E2B sandbox teardown isn't always instantaneous, and there can be slight clock drift or network latency between the client, Supabase, and the E2B control plane. A 10-minute buffer ensures that if a user's session just expired but they are actively saving their last changes, we don't aggressively nuke their work mid-operation. However, 10 minutes is short enough that even in a worst-case "rogue process" scenario, it won't trigger a meaningful billing spike. It’s the sweet spot.
2. MD5 Polling vs. ETag Polling:
Great catch! They serve two different paths:
hyna-stage watch): I completely replacedfs.watchwith MD5 hash-based polling.fs.watchis notoriously flaky, especially in Termux/Deno environments, and would sometimes trigger infinite loops or miss events. MD5 polling is bulletproof and cross-platform.hyna-stage watch --github): For this, we don't touch the local file system watcher at all. Instead, the CLI polls the GitHub REST API for new commit SHAs using ETag caching. This ensures we get instant updates without hammering the GitHub API or triggering rate limits.Building on a $150 phone forces you to be ruthless about performance and reliability. There is no room for flaky watchers or memory leaks!
Thanks again for the fantastic questions. Keep an eye out, v3.0.0 is right around the corner! 🐯☁️⚡
Right when I was about to go to bed 🛏️😴
Broo
Cool 😃
Bro your github link? 😃
Hey! Thanks so much! 😃
Here is the GitHub repo where all the magic (and the messy Termux debugging) happens:
🔗 github.com/harun-sket/hyna-stage
Feel free to star it, open an issue if you find any bugs, or just let me know what you think of the code. Always happy to chat with fellow builders! 🚀
@akhourianmolkumar bro what do you think ❤🔥
@technogamerz hey didi long time no speak
Sorry bro, how are you? :D