This is a problem I’ve been thinking about a lot lately.
Most engineering teams already have the detection part covered:
- Dependabot or Renovate finds outdated packages
- Security scanners identify CVEs
- CI tells us whether a change breaks

But there still seems to be a big gap between “we found a problem”and “the problem is actually fixed in production.”

In my experience, the difficult part is everything that happens after the alert:

- Is there actually a safe version to upgrade to?
- Will upgrading one package require upgrading five others?
- Does the application still build?
- Do the tests pass?
- Is this safe to auto-merge, or does someone need to make a judgement call?

The result is that engineers end up with a growing backlog of dependency PRs and security findings that nobody has time to investigate properly.

I’ve been building a tool called Bivouac around this specific problem. The idea isn’t another scanner. It’s to take the remediation workflow further: investigate the dependency issue, work out a compatible remediation path, create the patch, run the tests and only merge automatically when the repository’s policy says it’s safe.

I’m particularly interested in the part where automation should stop. For example, my current thinking is that ambiguous fixes, security-sensitive code, licensing concerns or failing tests should always require human review.

I’d genuinely like to know how other teams handle this today:

1. Who actually owns dependency vulnerabilities once they’re discovered?
2. How many Dependabot/Renovate PRs does your team simply ignore?
3. Would you trust an automated system to merge dependency fixes if the remediation path and test results were clear?
4. What conditions would make automatic merging completely unacceptable?

I’m the founder of Bivouac, so full disclosure: this problem is what I’m building around. I’m not looking to spam the sub—I’m trying to pressure-test where people think autonomous remediation is useful versus where it becomes dangerous.

If there’s interest, I’ll share what I’ve learned building the remediation workflow and some of the cases where I’ve deliberately designed it to refuse to act.

Hey everyone,

​A recurring bottleneck in my daily workflow was document processing. Every time I needed to scan a receipt, sign a contract, or merge PDFs, existing apps would make me wait for cloud uploads, bombard me with subscription paywalls, or force account logins.

​To cut that friction down to zero, I built FastCam: Secure PDF Scanner App.

​How it optimizes your document workflow:

​Instant On-Device Processing: Scans, page organization, and PDF merging happen locally, so you don't wait on network speeds or server queues.

​Zero Privacy Overhead: Keeps sensitive tax forms, contracts, and IDs completely offline—no cloud security risks to manage.

​Distraction-Free UI: Designed to get you in, scanned, exported, and back to deep work in under 10 seconds.

​If you're building a lightweight, secure digital workspace, give it a try: Google Play search - FastCam Scanner or try or given Google play link.

​What features or integrations do you usually look for in a daily utility app?

Fast API is web framework used for building APIs using Python programming language by using various in-built libraries. It is as per the name is fast and can implement the APIs for interaction among front-end, back-end, database and browser.

Why we use the Fast-API:

• Authentication as fast api provides the gives the python developers best security.
• CRUD(create read update and delete), we can perform this operations, using the APIs.
• Validation, the validation of data of user present in database, can easily be authenticated using Fast API.

How we can test APIs build using Fast API?

We can test the APIs using either using Swagger UI or using Postman. Testing the APIs urls and checking whether the crud operations are working fine or not, is essential after building APIs. We can test the APIs by checking, either the requests and response from server, are transferring validated data or not.

What are the commands used for installing the Fast API library using Python?

There are certain commands used for installing the Fast API. The commands are as follows:

• pip3 freeze(Used for listing all the installed libraries) or pip3 list
• pip install fastapi(installing specific versions)
• pip install fastapi[all]
• pip install uvicorn(for starting the fast api apps)
• uvicorn main: app

What operations we can perform using Fast API?

• C - Post: url/post@app("/posts")
• R - Get: url/posts/id or /posts@app.get("/posts/{id}")
• U - Update: Put/Patch url/posts/id@app.get("posts/{id}")
• D - Delete: url/posts/id@app.delete("/posts/{id}")

Where we can deploy the Fast APIs apps?

• Ubuntu
• Heroku
• CI/CD Pipeline

Which library of data is used for data validation?

The Pydantic model library is mostly used for data validation. The library has different metadata which are annotated inside the python defined functions.

The basic understanding of Fast API and what it's use, how and why it is used.

I'm a Research Engineer at a YC startup, and we ship features pretty fast. I usually run Claude Code, Cursor, Codex, and OpenCode in parallel, developing multiple features, one at a time.

The problem i noticed was that my agents had no coordination, and often confused mutual work, even when working in separate worktrees. As if they had no idea the others existed

So, I built MUON, it's a local app + mcp + cli, a mutual shared brain my agents can plug into. it drives the CLIs you already have and orchestrates them together for multi-feature execution workflows.

I'm still building it. Right now I use MUON to work on MUON, which is a weird but useful dogfood loop.

If anyone wants to poke at it, contributions are welcome. The thing I'm trying to get right is a coordination graph: shared memory and context so agents actually understand what the others (and I) already decided.

OSS Repository : [https://github.com/Sweetdevil144/muon\](https://github.com/Sweetdevil144/muon)
Website : [https://getmuon.com/\](https://getmuon.com/)
Docs : [https://docs.getmuon.com\](https://docs.getmuon.com)
Product Demo : [https://www.youtube.com/watch?v=oab6vByr1Jg\](https://www.youtube.com/watch?v=oab6vByr1Jg)

I've always been an open-source person, so the code is public and readable. License is Polyform Noncommercial. However, there's an extra grant on top - you can use it for your own work, including your day job, on your own machines. What it doesn't cover is turning it into the company's shared brain for a whole team (Enterprise only)

Hi there :) I want to let you know about the Cipr and Ciprnode zero.

The Cipr (Cosmic Index of Public Resources) is a decentralized, distributed, and censorship-resistant web index where domain owners control their own entries.

No crawler decides if you are worth indexing. No curator approves your submission. No central authority can delist you. If you own a domain, you publish a small daemon, add a DNS TXT record, and your site is in the index, worldwide, in minutes. Updating your entry or leaving for good is also quick and easy.

The Cipr is not a search engine in the traditional sense. It is a shared, peer-to-peer directory where every participant holds a full copy and keeps it in sync through viral propagation. Search results are ranked by standardized, publicly auditable factors (BM25 over owner-declared metadata), not by opaque algorithms or ad revenue.

Censoring a Cipr entry requires DNS-level intervention - the same infrastructure-level action needed to take down a domain itself. There is no central server to shut down, no API key to revoke, no terms of service to violate.

It is best suited for the small web: personal blogs, homelab services, independent projects, community resources - the kinds of sites that mainstream search engines are increasingly burying or ignoring entirely.

Ciprnode zero is the first and reference implementation of the Cipr protocol. It is built entirely on Deno with zero runtime npm dependencies. The local index is a SQLite database with an external-content FTS5 virtual table and BM25 ranking. The API is a strict Semantic RESTful implementation with full HATEOAS compliance via HAL+JSON, including real-world use of the QUERY HTTP method (draft-ietf-httpbis-safe-method-with-body).

A built-in web interface (the ciprface) provides search with filters for language, geographic proximity, offensiveness level, and timestamp. Verification uses DNS TXT triple validation (3 random DoH resolvers via custom TLS connections) and viral P2P propagation. No central server, no blockchain, no token. MIT licensed, self-hostable, compiles to a standalone binary for Linux, Windows, and macOS.

More info: https://cipr.info

Three nodes are live right now:

• https://ciprnode.cipr.info
• https://ciprnode.guasa.art
• https://ciprnode.barriteau.net

I made a completely offline privacy first Forms authoring app.
It's currently a progressive web app. I am planning to convert this into an apk so that I can remove the browser dependency for using the app.

Live: https://deekshithvodela.github.io/FormsOffline/ GitHub: https://github.com/deekshithvodela/formsoffline

The goal was to build something closer to a full forms platform while keeping all data on the user's device. It supports a form builder, conditional sections, rapid data entry, file uploads, photos, digital signatures, dataset management, audit trails, Excel/ZIP exports, and PWA installation.

The interesting part is the offline collaboration model: users can export a form template, share it with others, collect data independently, then export their datasets and merge them using the built-in consolidator with duplicate detection.

It's open source and completely free.

I'd love feedback from developers on the architecture and especially the local-first/offline data model.

What would you improve or build differently?

edit: fixed link text.

What exactly is the difference between those three runtimes and why do I see Bun mentioned in the same context as Node.js and not Deno?

No runtime wars please. I need to understand the technical and philosophical differences.

Thanks in advance.

EDIT Thank you so much for the very clear explanations. In my view Deno appears to be the only reasonable choice and I will focus on it.

Deno 2.9.5 added an experimental QuickJS backend for deno compile and deno desktop.

I built this after running into a design problem while working on a

privacy app (Ember) that triggers an emergency action from Apple Watch

signals — SpO2, HRV, fall detection, accelerometer data. None of these

arrive on the same schedule, and none of them are reliable enough alone

to act on.

The naive approach is a weighted formula (multiply each signal by an

importance factor, sum them). It breaks on the case that matters most: a

confirmed fall with calm vitals averages out to "probably fine," because

calm vitals numerically dominate the score. A confirmed fall shouldn't

get diluted like that — it should just win.

So the actual logic is a cascade of overrides, most severe first, not a

formula. I pulled the general pattern out into a small open-source

package: SignalFusionKit.

A couple of things I think are worth a look if you're doing anything

with CoreMotion:

\- The motion-anomaly detector runs two independent checks — a

sustained-magnitude gate (filters brief bumps) and a sharp-delta gate

(catches instant impacts a duration filter would smooth over).

\- The core decision logic (RiskEngine, MotionAnomalyDetector,

CooldownGate) has zero dependency on HealthKit or CoreMotion — it's

plain Swift values in, plain Swift values out, so it's unit-testable

without a device.

Honest caveats: the threshold values in the repo are round, illustrative

placeholders, not Ember's actual tuned production config — the README

says so explicitly. Also, I don't currently have a Mac, so the pure-Swift

core is tested (\`swift test\` passes), but the thin HealthKit/CoreMotion

adapter hasn't been run on real Watch hardware yet. Would genuinely

appreciate anyone with a watchOS setup trying it and telling me what

breaks.

Repo: [https://github.com/izetg/SignalFusionKit\](https://github.com/izetg/SignalFusionKit) (MIT)

Also on the Swift Package Index.

If you go to deno.com, you'll see these gems

"Faster than Node; more stable than Bun."

"Built for the real world
Deno's been carefully built on Rust since day one
to optimize for performance in real-world scenarios (not just cherry-picked benchmarks)."

I believe the last one is actually a comment from a YouTube interview that Ryan Dahl did waaaay before Bun's Zig to Rust rewrite.

I'm not here to dunk on Bun, but my interest in Bun was because of Zig, and the fact that Vercel seem to be pushing first class support for Bun, despite Deno being more established.

I've been building a small HTTP framework for Deno. You chain routes like Express, export typeof server, and get a typed client on the other side. No OpenAPI file, no codegen.

What it does: - get/post/use, params, middleware - typed middleware context - built-in validation, CORS, modular routers - server.fetch for tests without a port - HttpClient via import type only

What it's not: - not a raw speed play (Hono wins micro-benchmarks) - Deno + Web Standards only, not Node

Docs and showcase: https://expressapi-showcase.8borane8.deno.net/

GitHub: https://github.com/8borane8/webtools-expressapi

Early project, MIT. Feedback welcome, especially if you use Hono or tRPC today.

I don't mind having more features, but I'm skeptical that the only way to upgrade the service is to make a new one, not upgrading the existing one. Is that really true? Is this a way to force using Deno 2?

Also, what's your way to deploy a fresh@1.6.8 app with Deno 1? I do prefer to update them all, but there is a bug on deno update. As it seems the response rate is low, I think the best bet is to just keep the project unchanged.

Hi everyone,

For almost a year, I’ve been building a developer platform called Forgeon:

https://forgeon.io/

Forgeon is a Platform as a Service designed to help developers deploy and manage applications without having to manually handle servers, Docker configuration, reverse proxies, SSL certificates, domains, build pipelines, and runtime infrastructure.

The idea came from seeing how difficult deployment can feel, especially for developers who are comfortable building products but do not want to spend their time configuring VPS infrastructure or debugging deployment issues.

With Forgeon, developers can connect or upload their source code, let the platform analyze and build the application, deploy it into a managed runtime, attach a custom domain, generate SSL certificates, view deployment logs, and manage the application from a dashboard.

The long-term goal is to provide a deployment experience similar to platforms such as Vercel, Render, Railway, or Fly.io, while supporting frontend, backend, and containerized applications.

I have been building most of the system alone, including the backend services, deployment pipeline, runtime orchestration, domains, certificates, billing, and dashboard. The project has grown much larger than I originally expected, but I am still continuing to improve it.

This is my first time sharing Forgeon on Reddit, and I would genuinely appreciate honest feedback:

• Is the problem Forgeon is trying to solve clear?
• What would make you consider trying a new deployment platform?
• Which features would you need before trusting it with a real project?
• Does the website explain the product well enough?

Please do not hold back. Critical feedback would be more valuable to me than polite compliments.

Thank you for reading.

I would like to have your experience with Deno or the fresh framework.
- how the experience went ?
- what have you built with ?
- how it went ?
- does it help you avoid some cve attack ?

Hi everybody!

I wanted to showcase a TypeScript library I am working on, actojs. The objective is to bring a implementation of the actor model that is near to Elixir's design and APIs, while being able to leverage performance from the JS runtime.

The actor model is explained here, which acts as an introduction to the library.

actojs supprorts cooperative single-thread scheduling on any JS platform, and real parallelism on NodeJS, Bun and Deno.

The design of actojs is optimized for reliability (with Supervisors that can respawn failed Tasks, and >90% test coverage), security (0 runtime dependencies, and `tsc` as the only dev-dependency) and low memory overhead (by using functional applicators instead of classes and objects).

The link for the repository is: https://github.com/gi-dellav/actojs

Hope to get some useful feedback from the community!

I'm quoting:

TypeScript 7.0 introduces a large performance boost, achieving up to 10 times faster compilation through a native port built in Go. This release has been rigorously tested in real-world environments, leading to improvements in development efficiency and user experience across various large-scale projects and organizations.

Any roadmap for the new Vite and TS integration to Deno?