It does sound cool and as an infra nerd myself it reads sensible, I just don't see why I would want another abstraction layer between my cloud deployments being rolled out and the tf/hcl files that I maintain. Why would I want to install another interface between me, the planfile and the running environment? Genuine question
It’s opinionated and built around a reference architecture- think it kind of like using rails or phoenix instead of just writing ruby or elixir. LLM’s are fantastic syntax generators, but they have no real opinions on architecture or finops.
Oh so more an orchestration interface with sane defaults for an LLM to use as a reference when implementing deployment changes, especially new rollouts?
It seems to be aimed at small to medium sized cloud deployments and more as a starting point to get customers up and running?
Because I'm already administratrating a large AWS environment and the networking, especially as regards route tables, transit gateways, DMZs and extensive security group rules managed in multiple distinct layers across teams (and don't even get me started on IAM and Active Directory Forest) don't seem to fit into the abstraction layer I'm seeing.
Exactly - and it's pretty much aimed at 'built this cool TS app on vercel and supabase and want to scale it' or the like. I build my career migrating rails apps off heroku, and this is kind of inspired by a lot of what I learned.
Are you using IaC to administer all of this or just handjamming in the console? I'd love to expand neckbeard to handle more complex enterprise motions - the landing zone scenario your speaking of is particularly an interesting use case, I'll start thinking on it!
> The same reference app (HTTP service + worker + cron + Postgres), smallest tier, all three environments, live prices via Infracost:
Hetnzer server for 25usd/month and you have plenty more space to do more stuff and scale
Can this be used with the ponytail skill? https://github.com/DietrichGebert/ponytail/tree/main
It should be compatible yeah - ponytail was the inspiration for this - ideally one could use ponytail for application code and neckbeard for infra.
It does sound cool and as an infra nerd myself it reads sensible, I just don't see why I would want another abstraction layer between my cloud deployments being rolled out and the tf/hcl files that I maintain. Why would I want to install another interface between me, the planfile and the running environment? Genuine question
It’s opinionated and built around a reference architecture- think it kind of like using rails or phoenix instead of just writing ruby or elixir. LLM’s are fantastic syntax generators, but they have no real opinions on architecture or finops.
Oh so more an orchestration interface with sane defaults for an LLM to use as a reference when implementing deployment changes, especially new rollouts? It seems to be aimed at small to medium sized cloud deployments and more as a starting point to get customers up and running?
Because I'm already administratrating a large AWS environment and the networking, especially as regards route tables, transit gateways, DMZs and extensive security group rules managed in multiple distinct layers across teams (and don't even get me started on IAM and Active Directory Forest) don't seem to fit into the abstraction layer I'm seeing.
Exactly - and it's pretty much aimed at 'built this cool TS app on vercel and supabase and want to scale it' or the like. I build my career migrating rails apps off heroku, and this is kind of inspired by a lot of what I learned.
Are you using IaC to administer all of this or just handjamming in the console? I'd love to expand neckbeard to handle more complex enterprise motions - the landing zone scenario your speaking of is particularly an interesting use case, I'll start thinking on it!
The real Gilfoyle would self-host.
do as neckbeard says, not as neckbeard does.
Sometimes the name of a product makes me want to use it, even if I don’t have uses for it. This is such a name, I just keep on grinning.
The beard is the wrong color, but otherwise: agree.
This makes my day - I genuinely love naming things, as an artist and a technologist it's fun to inject some creativity into the code!
I have the opposite feeling about CoackroachDB. Great database, but man, what a terrible name.
Why not opentofu and ansible? Version and run it. I don’t see why i need this.
If you write your own tofu and use ansible you probably don’t - this is aimed more at containers/serverless.
Something to try for sure. Company recently migrated some ancient on prem databases to AWS, would've been useful then perhaps.
Thanks! Give it a try next time you need to provision infra.
the readme is cringe and painful to read. please take a minute to tone the claudisms down.
definitely on my todo list - I was educated in the American south so you might regret this!
I doubt it, bad grammar is better than AI-speak.