[HN Gopher] Show HN: We Put Chromium on a Unikernel (OSS Apache ...
___________________________________________________________________
Show HN: We Put Chromium on a Unikernel (OSS Apache 2.0)
We've been building infrastructure to spin up browsers for AI
agents. Originally, we built[0] it as a pool of warm Docker
containers running Chromium, exposing: - Chrome DevTools Protocol
(for Playwright/Puppeteer) - noVNC (for live view) We've been
following the unikernel space for a while, so we decided to see if
we could get our image on one. We went with Unikraft Cloud[1].
Here's how it did: - Boot-up time: 10-20ms (vs. ~5s for Docker
containers) - Near 0 CPU/memory consumption when idle - Still
~8GB RAM when active (headful Chromium) Potential use cases: -
Standby mode during long-running jobs: unikernels can sleep after X
sec of inactivity, reducing clock time costs - Session reuse:
auth/session cookies persist for hours/days. Basically as long as
the cookies are valid - Cold start speed: good for low-latency,
event-based handling We open sourced it with Apache 2.0! Feel free
to fork or submit an issue / PR. Open to feedback or suggestions.
www.github.com/onkernel/kernel-images == [0]
https://github.com/onkernel/kernel-images [1]
https://unikraft.cloud/ [2] Thanks to the Unikraft Cloud team
@fhuici @nderjung @razvandeax for helping us figure this out (we're
not affiliated) [3] (OPs) @rgarcia @juecd
Author : juecd
Score : 59 points
Date : 2025-04-16 13:19 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| juecd wrote:
| (OP) Happy to answer any questions! Some things we're still
| exploring:
|
| - Mounting persistent storage for file i/o
|
| - Replacing noVNC with a faster alternative
|
| Would love feedback, especially if you've worked on fast-cold-
| start systems or unikernel-based infra.
| jay-barronville wrote:
| Impressive work, @juecd!
| juecd wrote:
| Thank you!
| shaqbert wrote:
| 5s for Docker containers vs 20ms now ... holy moly, this is fast
| juecd wrote:
| From what we've seen, micro VMs could probably do something
| very fast too (150ms?) but we thought 20ms was pretty crazy.
| rollcat wrote:
| Interesting work. It immediately brought boot2gecko to my mind.
| If I understand unikernels correctly - do you think it would be
| viable to run this on real HW?
| shykes wrote:
| This looks excellent, and very fun to play with!
|
| I used this one-liner to run an instance directly from remote
| source: dagger -c 'git
| https://github.com/onkernel/kernel-images | head | tree | docker-
| build --dockerfile containers/docker/Dockerfile | up --ports
| 8501:8501,8080:8080,6080:6080,9222:9222'
|
| Be aware that the initial docker build is quite long... But
| caching kicks in for subsequent runs.
|
| I look forward to playing with this!
| tyre wrote:
| This is super cool. We've been looking into infra for AI agents.
| As others have noted, the difference in speed alone between
| docker and this is a huge win. Having our clients wait around for
| five seconds really adds up.
|
| Awesome tech, excited to dig deeper for healthcare
| juecd wrote:
| Thank you!
| capiki wrote:
| Cool (and congrats on the demo)! Sounds like a promising
| approach. I work on browser use agents and one of the most
| difficult problems now is bot detection. Curious if you know how
| this impacts bot detection/fingerprinting?
| juecd wrote:
| Thank you! Yeah, the current implementation basically performs
| the same as a Docker container (i.e. not much). The interface
| is the same, so you can use BU/Playwright/Puppeteer's header
| configs to change as needed.
|
| We did notice the unikernel cloud instances don't run into bot
| detection as often as our hosted docker instances, but I think
| that's mostly because Cloudflare haven't flagged Unikraft
| Cloud's IPs yet, hah.
| HyprMusic wrote:
| I'm assuming the low latency cold starts are from a paused state,
| considering chrome itself takes a few seconds to boot? Or have
| you found some clever way to snapshot a running chrome and fork
| that?
|
| Either way thanks for sharing.
| rgarcia wrote:
| It snapshots / pauses the entire unikernel instance after
| launching chromium, and then resumes the instance in <20ms with
| exactly the same state.
| crowcroft wrote:
| This is probably a dumb question from someone who knows almost
| nothing about system engineering.
|
| How hard would it be to boot a computer to this as an OS?
| csdvrx wrote:
| You would have to add support for the peripherals in the
| kernel, and have some kind of init system. You would also need
| a filesystem supported to boot the computer.
|
| I was doing something similar for the entire OS a few years
| ago: cosmopolinux, a distribution of cosmopolitan binaries:
| https://github.com/csdvrx/cosmopolinux
|
| My idea was to replace the WSL binaries to have a Linux
| distribution living on C:\, but that could also be booted
| baremetal if you didn't want to use Windows
|
| I had to put together a multi stage init system for that: if
| you get the ISO, you can put in on a thumbdrive and boot it:
| https://gitlab.com/csdvrx/cosmopolinux
|
| The only difference between them is the kernel and the
| filesystem: the github NTFS has a firecracker linux kernel, the
| gitlab ISO has a regular kernel with many modules.
|
| I wanted to do a full NTFS solution but I couldn't find a
| bootloader I liked that would support booting from a NTFS
| partition.
|
| Booting from an ISO was simpler and faster.
___________________________________________________________________
(page generated 2025-04-16 17:00 UTC)