HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
aspectrr
fluid
Systems & Infrastructure2026–2026
aspectrr / fluid

fluid

The all-in-one daemon for fully autonomous agents to work on infrastructure

Systems & Infrastructure
Explore on GitHubRead Hacker News discussions
2Distinct people
2Mentions
0Explicit recommenders
0GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The all-in-one daemon for fully autonomous agents to work on infrastructure

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by day2 dated mentions

Observed mentions: 2026-01-13 18:39:14 UTC to 2026-02-05 01:51:43 UTC.

012026-01-13 00:00:00 UTC to 2026-01-14 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 commentsJan 132026-01-14 00:00:00 UTC to 2026-01-15 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-15 00:00:00 UTC to 2026-01-16 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-16 00:00:00 UTC to 2026-01-17 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-17 00:00:00 UTC to 2026-01-18 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-18 00:00:00 UTC to 2026-01-19 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-19 00:00:00 UTC to 2026-01-20 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-20 00:00:00 UTC to 2026-01-21 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-21 00:00:00 UTC to 2026-01-22 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-22 00:00:00 UTC to 2026-01-23 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-23 00:00:00 UTC to 2026-01-24 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-24 00:00:00 UTC to 2026-01-25 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsJan 242026-01-25 00:00:00 UTC to 2026-01-26 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-26 00:00:00 UTC to 2026-01-27 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-27 00:00:00 UTC to 2026-01-28 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-28 00:00:00 UTC to 2026-01-29 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-29 00:00:00 UTC to 2026-01-30 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-30 00:00:00 UTC to 2026-01-31 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-31 00:00:00 UTC to 2026-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-02-01 00:00:00 UTC to 2026-02-02 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-02-02 00:00:00 UTC to 2026-02-03 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-02-03 00:00:00 UTC to 2026-02-04 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-02-04 00:00:00 UTC to 2026-02-05 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-02-05 00:00:00 UTC to 2026-02-06 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsFeb 5

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jan 132026-01-13 00:00:00 UTC2026-01-14 00:00:00 UTC110
Jan 142026-01-14 00:00:00 UTC2026-01-15 00:00:00 UTC000
Jan 152026-01-15 00:00:00 UTC2026-01-16 00:00:00 UTC000
Jan 162026-01-16 00:00:00 UTC2026-01-17 00:00:00 UTC000
Jan 172026-01-17 00:00:00 UTC2026-01-18 00:00:00 UTC000
Jan 182026-01-18 00:00:00 UTC2026-01-19 00:00:00 UTC000
Jan 192026-01-19 00:00:00 UTC2026-01-20 00:00:00 UTC000
Jan 202026-01-20 00:00:00 UTC2026-01-21 00:00:00 UTC000
Jan 212026-01-21 00:00:00 UTC2026-01-22 00:00:00 UTC000
Jan 222026-01-22 00:00:00 UTC2026-01-23 00:00:00 UTC000
Jan 232026-01-23 00:00:00 UTC2026-01-24 00:00:00 UTC000
Jan 242026-01-24 00:00:00 UTC2026-01-25 00:00:00 UTC000
Jan 252026-01-25 00:00:00 UTC2026-01-26 00:00:00 UTC000
Jan 262026-01-26 00:00:00 UTC2026-01-27 00:00:00 UTC000
Jan 272026-01-27 00:00:00 UTC2026-01-28 00:00:00 UTC000
Jan 282026-01-28 00:00:00 UTC2026-01-29 00:00:00 UTC000
Jan 292026-01-29 00:00:00 UTC2026-01-30 00:00:00 UTC000
Jan 302026-01-30 00:00:00 UTC2026-01-31 00:00:00 UTC000
Jan 312026-01-31 00:00:00 UTC2026-02-01 00:00:00 UTC000
Feb 12026-02-01 00:00:00 UTC2026-02-02 00:00:00 UTC000
Feb 22026-02-02 00:00:00 UTC2026-02-03 00:00:00 UTC000
Feb 32026-02-03 00:00:00 UTC2026-02-04 00:00:00 UTC000
Feb 42026-02-04 00:00:00 UTC2026-02-05 00:00:00 UTC000
Feb 52026-02-05 00:00:00 UTC2026-02-06 00:00:00 UTC101

What Hacker News says

2 sources
aspectrr·Jan 13, 2026Submission

Show HN: Fluid.sh – Make Infrastructure Safe for AI

Hey HN, My name is Collin and I built fluid.sh because I wanted AI agents to work on my infrastructure safely and give the boost that Claude Code has given to me, to fellow Infra engineers. I built this as I work with infrastructure a ton in an enterprise incumbent and wanted to let agents work on our infrastructure rather than suggest stuff. The problem: We can give AI agents root access to codebases, but not to servers. One bad command on production and you're getting paged at 3 AM. So we limit agents while humans do the actual execution. We don't get the same feedback loops software engineers do. The solution: Give the agent root access to an isolated VM instead. Let it work autonomously—provision servers, configure firewalls, set up services, deploy applications. Then diff the changes, review what it did, and approve an Ansible playbo
Read the rest
ok to apply to production. How it works: 1. Clone a golden VM image into an isolated KVM sandbox 2. Agent gets full root access and works autonomously 3. Snapshots checkpoint progress (rollback if needed) 4. Diff snapshots to see exactly what changed 5. Auto-generate Ansible playbook from the agent 6. Human reviews and approves (blocking workflow) 7. Playbook applies to production Tech stack: Go + libvirt/KVM, React, Python SDK, PostgreSQL Use cases: - Autonomous server provisioning and configuration - Self-healing infrastructure (agent diagnoses and fixes issues) - Migration automation (agent figures out the steps) - Compliance remediation - On-call automation (agent triages and resolves alerts) Why VMs instead of containers? - Full OS isolation (not namespace isolation) - Real networking stack for firewall/routing work - Snapshot/restore is native to the hypervisor - Agents can reboot, modify kernel params, install kernel modules - Closer to production reality GitHub: https://github.com/aspectrr/fluid.sh Demo video: https://youtu.be/nAlqRMhZxP0 Happy to answer questions or feedback!
2 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.