Bitwarden/Vaultwarden had a good run but if someone's going to self-host Vaultwarden, I would encourage people to look into AliasVault instead. It's a complete opensource ecosystem.

I believe they still allow API usage in this manner though.

In this case, the OP attempted to use Zed with Anthropic's $20/mo plan and was banned immediately. I imagine if they had went the API usage route, this wouldn't have transpired.

Surprisingly, I wonder if this will push more people to use Cursor because they allow you to use a variety of models, including SOTA. That, or manage your own API key subscriptions with a middleware like LiteLLM that also monitors usage so that your coding frenzy doesn't turn into a $20k bill. Or maybe OpenRouter where you manually top up the account.

You can substitute Pulumi for Terraform, PyInfra for Ansible and google for sample projects that use Terraform and Ansible to get a good idea of their strengths and how they come together.

Then, you take that understanding and you realize using PyInfra and Pulumi, you can do all of that in just Python, using all of Python's rich ecosystem.

Yes, it feels a bit weird to me that the HN crowd is a fan of regulation although much of the crowd works in the least regulated profession.

Maybe we need to have regulation that puts an automatic expiration on regulation and there's no way to bypass that. Existing regulation nearing expiration can only be extended by a democratic voting process. Just the burden of handling this should naturally filter out regulation that's unpopular or no longer relevant.

If you're reading this, I'll indulge and reask you the two questions:

- question 1: There's clearly a demand for a "Python as a DSL" for infrastructure projects - CDKTF/Python, CDK/Python, Pulumi, cdk8s etc are very popular. I would have imagined pyinfra to be way more popular and ubiquitous than it really is! Do you have thoughts on why pyinfra isn't more popular? How do people typically discover pyinfra? I would imagine any Python dev would intuitively grab pyinfra over Ansible?

- question 2: Do you have any thoughts about cdk8s? As you know well, Kubernetes has similar YAML "hell," and as someone who spends significant resources on pyinfra, I would guess you have given something like cdk8s thought?

I'm happy to engage either over email or here, don't have a preference.

Again, Thank You for building and sharing pyInfra.

That said, DBOS really makes durable workflows accessible and approachable. Having already used Temporal, I think you're really appreciate how quickly you can get started with DBOS. I forget if they support SQLite but if you have a PostgreSQL server set up, you really don't need anything else to write your first few DBOS durable workflows (vs. needing a Temporal server or cluster)

Let me know if I got you interested to try it out. I first learned about Temporal from Mitchell Hashimoto as they were using it for Hashicorp Cloud. Eventually I discovered DBOS and now all my personal projects are on DBOS.

There used to be a project called Benthos (since acquired and rebranded by Redpanda in 2024) that was amazing, that you might want to gain some inspiration from.

However, durable workflows have also gained popular acceptance as functional design reaches a wider audience.

While Temporal is the most popular choice when it comes to durable workflows, DBOS (cofounded by the father of PostgreSQL) is my personal favorite.

At the moment, orchestration in DBOS has certain gaps - you might very well consider spending your effort on closing those gaps. The value there would be phenomenal!

I argue that easier they make for user to swap batteries themselves, higher the demand for the batteries will be, thus lower their price.

> The needed mechanism and the protective shell the replaceable battery needs definitely takes up space

This is true

> The real problem I think is the hostility towards repair, glue everywhere, no spare parts, etc.

I think when a manufacturer isn't designing to allow a regular customer (the owner) to be able to replace the battery themselves, using glue and restricting spare parts is a natural consequence of financial realities: Most people are not going to take a $500 phone that has been used a few years to a shop that will need to charge $100+ in just labor to swap out a battery. So there's no incentive to have a bunch of spare batteries.

I'm a huge fan of user replaceable batteries because in addition of obvious benefits, you can also just remove the battery and power it simply off USB-C when running something heavy on the phone for extended periods of time. A battery used in that scenario wouldn't just overheat itself but stop the phone from cooling off too.

I never put my phones in my back pocket nor do I wear butt hugging leggings, so having a thick phone stick out my ass and make it look bad isn't on my list of worries. I end up purchasing thick waterproof cases for these slim phones anyways.

What's most confusing is the premium phones lack replaceable SD cards and batteries - it's like they are trying to take the worst ideas from the Apple ecosystem and simply don't understand why some people use Androids.

Surprisingly, it's the cheaper models that carry replaceable SD cards and batteries - I would have imagined the opposite!

I often go on trips and hikes with poor cellular coverage and having some SD cards with useful information or being able to swap them out as the camera gets full is really helpful. Attaching drives over the USB port isn't really practical.

When I do have cellular coverage, I might have to rapidly download a LOT of data, which overheats the phone and discharges the battery. With a replaceable battery, this isn't even an issue.

The benefits of replaceable batteries cannot be overstated when you're not on the grid or take great care of the phone where they last more than a few years. I can have a few batteries charged, during the day using solar that I can then just swap them in as evening sets in, instead of having to plug the phone into a powerbank and pray it doesn't shut off as I keep using it.

TBH, I was worried a few years ago that there was basically just one (original) contributor. This now gives me added trust that I'm taking the right decision to lean heavily into it.

I hope more people start using pyInfra.

Thank You for your contribution and attention!

If you're a software engineer who wants to setup and maintain infrastructure, give PyInfra and Pulumi a go!

Huge fan of PyInfra. For my homelab, I use Pulumi with Python and PyInfra to build fully declarative intent based infrastructure. You can use actual software engineering principles like composition, inheritance, DI to setup and wire your infrastructure and services. One of the benefits of this is your infrastructure and services are now self documenting (have them write out a mermaid diagram!) and easily testable using pytest (from cheap unit tests to extensive integration tests (I use Incus)).

Instead of Pulumi, I originally used Terraform CDK with Python before CDK got IBM'd. The migration to Pulumi was refreshingly painless. My original reason for not choosing Pulumi was the crippled state of the open source, self hosted backend support a decade ago but it looks like that is now way more mature and less crippled.

PyInfra is a breath of fresh air compared to Ansible - its not just fast, it's more Pythonic, so IDE features actually work, readable, maintainable, debuggable. I call it infrastructure for software engineers.

If anyone wants to use an AI agent to try out PyInfra - One issue I've faced is that PyInfra was rearchitected in v2 (and some more in v3?) but what belongs in v1 vs v2 vs v3 isn't very clear, so an AI agent could spend a lot of time writing v1 code, having it fail and iterate to v2 and then to v3.

The official site uses the version in the URL as the namespace but it seems like the SOTA AI agents don't pay much attention to that.

Maybe writing a llms.txt for PyInfra v2, or v3 would be an extremely useful task to help with onboarding newcomers?

---

The original post by the OP https://news.ycombinator.com/user?id=wowi42:

Disclosure: PyInfra core contributor here. We just shipped 3.8.0.

PyInfra is an agentless infrastructure automation tool. Same job description as Ansible, Salt, Chef. SSH into hosts, describe desired state, it diffs and converges. No agent, no central server, no daemon.

The difference: your "playbook" is just Python. Not Python cosplaying as YAML. Not Jinja smuggled inside YAML inside a Helm chart inside a Kustomize overlay. Actual Python:

    from pyinfra.operations import apt, files, server

    apt.packages(packages=["nginx"], update=True)
    files.template(src="nginx.conf.j2", dest="/etc/nginx/nginx.conf")
    server.service(service="nginx", running=True, enabled=True)

PyInfra skips the eleven good minutes and goes straight to code.

Release notes in the link. Happy to answer questions.

Infrastructure as Code, not infrastructure as YAML.

I am extremely happy for you!

This is fantastic news. I would really appreciate a followup post on DB SE and/or PostgreSQL ML because I assure you, there are others in your position. A deeply nested HN thread is not something that will be visible - you would be saving a lot of people heartburn.

Also remember, we just got started! The tips I gave you earlier is just a drop i the bucket. In the days of AWS RDS, knowledge about these are a "lost art" but running PostgreSQL yourself is extremely empowering. If you could make the posts, please do and I also urge you to test out https://github.com/pgsty/pigsty

Thats a fantastic question. Here's my take: https://news.ycombinator.com/item?id=47917314 - would love your thoughts on it.

In short, I think you're asking a billion dollar question - how do we solve the verification, validation, and QA bottleneck?

The way I handle it for my personal projects is I invest tremendous time and effort into writing thorough test and validation suites.

I bet the next billion dollar companies will be those addressing this verification, validation, and QA bottleneck.

Not necessarily. I went into a bit more detail in my own comment but it might be useful to think that when regulations are written keeping in mind multibillion dollar automobile companies, what the effect of those regulations on a person maintaining their own vehicles might be.

Consider that your Waymo got ticketed, but you had flashed it with a "no customer telemetry" firmware. Once Waymo gets the ticket, they flag your car as having "unauthorized" software and now the ball's in your court that the reason why your Waymo got ticketed has nothing to do with the telemetry feature that tells Waymo what radio stations you were listening to.

Also, when regulations are written keeping in mind multibillion dollar automobile companies, the ticket isn't going to cost $500.

> the car is basically a taxi and the taxi service is to blame for any mistakes

@skybrian - Agreed! but if you read the article, the CA DMV is ticketing the manufacturer, not the operator.

None of my concerns hold if the operator was ticketed - infact, existing regulations are set up exactly that way, so no new regulation was even necessary. Something's not adding up.

> Right now, no one can independently own and operate an AV the way Waymo or Tesla does

@ourspacetabs - Sure but the regulation seems to be specifically addressed at the manufacturer, not the operator.

I would have no concern if the regulation was addressed to the operator. The article atleast doesn't imply that's the case.

---

> The state's Department of Motor Vehicles (DMV) has announced new regulations on autonomous vehicles (AVs), including a process for police to issue a "notice of AV noncompliance" directly to the car's manufacturer.

> Under the new rules, police can cite AV companies when their vehicles commit moving violations. The rules will also require the companies to respond to calls from police and other emergency officials within 30 seconds, and will issue penalties if their vehicles enter active emergency zones.

These are new frontiers in automotive regulation. Typically, if a car failed because of a manufacturer issue, the driver would be ticketed. For example: if Hyundai sold vehicles where the engine would explode around 50k miles and that caused an accident, the driver of the vehicle would be ticketed for it.

Now if we take the human out of it, it is Hyundai that would be ticketed for it. Insurance companies are certainly going to take notice and adjust their risk models accordingly.

I imagine there will be a lot of fingerpointing by the manufacturer towards customers.

In the worst case, this is the end of customers servicing their own autonomous vehicles.

If we imagine that most vehicles in the next 15 years will be autonomous, this would mean customers would have to handle regulation aimed at multibillion dollar companies, if they were to service their own autonomous vehicles, or give up on servicing their own autonomous vehicles entirely and just rent them instead.

- CRUD generation by running through JIRA tickets and clearing backlogs seem to be replaced by agentic workflows. So if you were an extremely productive dev who would machete your way through CRUD and API integrations, agentic workflows do it better, faster and for cheaper. I can point CC, Codex (Cursor in progress) at design specifications and it can turn those into perfect Django apps with well written test cases like there's no tomorrow. It might not make sense for such a business to continue to hire humans to do the same work

- Tokens for frontier models over the API are really expensive. I am personally aware of some companies that have monthly high five figure token expenses and one company that has a monthly six five figure token expense.

It's still worth it because they are churning out code 24x7 vs a typical human's 8x5 if you're putting in the right workflows, guardrails in place - that's a 4x productivity gain.

You're getting done in a month, what a full quarter would require humans to do. However, the company still has to pay for that and unless they are signing up 4x more paying net new customers every month with 0 churn, engineers have to be let go to pay for those tokens.

right and here's why CloudNativePG chose Barman over pgBackRest: https://github.com/cloudnative-pg/cloudnative-pg/issues/3077

> WAL limits need to be set carefully or you just end up filling WAL volumes and the database becoming unavailable.

This is true. For anyone getting alarmed that this is due to a bug in PostgreSQL, it's not - it's PostgreSQL protecting the customer from attempting to write data that it cannot durable commit - "I am going to go unavailable because I don't have enough space to save more data".

There are multiple ways to handle this, the easiest, most hands on way is to keep a monitor and alert that watches the WAL size like a hawk and then alerts OPS the moment it breaches a threshold.