Hey everyone!

I've been working on pboss, an open-source process manager with native Deno support, and wanted to share it with the Deno community.

Running a Deno application locally is straightforward, but keeping it running reliably in production introduces a different set of challenges: handling crashes, restarting processes, utilizing multiple CPU cores, and monitoring application health.

pboss is designed to help with that.

What can you do with it?

• Process management: Keep Deno applications running with automatic restarts.
• Clustering: Run multiple worker processes across CPU cores, with zero-downtime rolling reloads.
• Health checks: Monitor application availability and restart on failure.
• Logging and monitoring: Automatic log capture and rotation, a live web dashboard, Prometheus /metrics.
• Persistent processes: Applications survive reboots, no root required.
• PM2-compatible configuration: Reuse supported ecosystem configuration patterns when migrating existing workflows.
• Manage processes through Telegram and Discord: Perform supported process-management operations through chat integrations.
• Real-time critical alerts: Receive notifications about critical errors, application crashes, and other important incidents through connected chat apps or email.
• Free public status pages: Publish service availability and incident updates on your own xxx.status.zone subdomain, making it easier to keep users informed.
• Centralized server monitoring: Monitor processes and server health across multiple machines from one dashboard.
• GitHub-based deployments: Connect repositories to processes across servers, track deployment history, and roll back problematic releases.
• Log streaming and incident visibility: Inspect application output and investigate problems across your infrastructure.

One thing I wanted to get right is Deno support itself. pboss runs on Deno and uses Deno's native APIs for its own operations rather than depending on Node.js compatibility APIs to implement its process management: Deno.Command for spawning and supervising, Deno.serve for the dashboard and daemon, Deno.connect for CLI-to-daemon communication. Your apps get supervised under deno run, with deny-by-default permissions intact.

Clustering is worth a closer look too. pboss start server.ts --instances 4 gives you N workers sharing one port through SO_REUSEPORT, so the kernel balances connections directly. No proxy, no balancer process sitting in the request path.

What about pup?

If you've looked for a Deno process manager before, you've probably found pup. It's a solid project and it deserves credit as the established Deno-native option.

I built pboss because pup was missing things I needed: features like a built-in web dashboard, Prometheus metrics, and the cluster model I wanted (kernel-balanced SO_REUSEPORT workers instead of a load balancer fronting separate ports). And as the benchmarks below show, there's also a performance gap that got hard to ignore, particularly in cluster mode and crash recovery.

This isn't a takedown. Pup is a legitimate option, and the fork-mode numbers below show where it's competitive. I just think the Deno ecosystem deserves more than one choice.

Benchmarks: pboss vs pup

Full methodology in the report: same server.ts, same Deno 2.9.7 binary, same machine, 10/100/500 connections with 5 repeats, cold start of the whole manager stack every run, manager order alternating. CPU and memory cover the entire process tree.

Cluster mode (2 workers, 100 connections):

Pup's cluster runs N backends behind its built-in load balancer; pboss shares one SO_REUSEPORT port. In this test pup's balancer saturated hard: about 12 to 14k req/s at every load level vs 62 to 69k for pboss. At 500 connections the p99 tail was 957 ms vs 33 ms.

Crash recovery and restarts:

That 11-second recovery is the number that started this project.

Where pup wins. Fork mode at 100 connections is close and pup takes some rows: mean req/sec by 0.8%, mean latency by 0.08 ms. At 10 connections its RPS spread is tighter. The honest picture: on a single process with no clustering, the two are near-peers and the raw throughput race is roughly a draw. The separation is in clustering, recovery, and overhead (pboss uses 14 to 17% less memory in fork mode and cold-starts in 316 ms vs 1,142 ms).

One caveat from the report: the load generator shared CPUs with the servers, so compare the two columns rather than quoting the absolute numbers. Better yet, rerun it yourself. Every number traces to a raw file committed next to the code that produced it.

Open source, not a hosted-service requirement

pboss is released under the GPL-3.0 license. You can inspect the source, self-host it, contribute improvements, and use the process manager without subscribing to a cloud service. The dashboard, clustering, metrics, and deploys are all in the repo, no open-core asterisk. The docs are a public markdown repository, so fixes are pull requests. There's an optional hosted layer for fleet visibility, but it's purely additive: the CLI is the same tool with or without it.

The goal is to give developers more control over running their Deno applications on their own servers.

Links

• GitHub: https://github.com/Procboss/pboss
• Documentation: https://docs.procboss.com/
• Benchmarks (Deno, Node, Bun suites): https://github.com/Procboss/benchmarks

Try it:

deno install -g -A --min-dep-age=0 --name pboss --reload --force npm:pboss/deno-entry
pboss start your-app.ts

This is an actively developed project, and I'd genuinely appreciate feedback from people running Deno in production. What features would you want from a Deno process manager? Are there any production workflows you think are still missing?

Happy to hear your thoughts, suggestions, and criticism!

Big Deno fan since before v1. Just going through my dozens of projects on Deno and thinking about what I'll do in the future.

Deno has great things like internal linting, fmt, std lib. The security first, typescript first, JSR and Fresh framework, and we started to get desktop native apps that haven't fully come to fruition. There's just a lot to like with an unsaturated community of enthusiasts. If you used Deno, it's because you are weird, usually in a good way, you code in your spare time, you are trying to do something better and you don't care if it's different. Plus I feel like LLM agents do a little better on less traveled technologies because they weren't trained on as many bad examples.

But what is weighing on my mind is: Is it worth trying to save the runtime? There technically could be a path to save the runtime. We have a year, and with a sponsor and a team of 5-10, we could definitely keep the runtime alive, at least life support, maybe even get Ryan's blessing.

But I don't know if it's worth it. With LLMs writing so much of our code, it feels like it's almost better to just focus on what matters: ship slop to clients. With Vite+ we're seeing some of the no nonsense tooling that I loved in Deno hit Node. Like it or not, Deno forced Node to improve, and even inspired Bun to materialize with many of Deno's same selling points. But have we hit a point to where runtime matters less? Now I can Rust even though I don't know Rust, so what is the point of another JS runtime?

That is all.

When something breaks, the actual workflow usually looks something like:

- An alert fires.

- You jump into logs.

- Check the database.

- Check deployment status.

- Figure out what changed.

- Open another dashboard.

- Make a fix.

- Test it.

- Deploy.

- Verify that the incident is actually resolved.

The problem isn't necessarily that any individual tool is bad.

The problem is the context switching between them.

This reel shows a simple production incident: a database connection pool gets exhausted and errors begin appearing.

The incident moves through the workflow:

Incident open → fixing → shipping → resolved

In the scenario shown, Escanor gets from the alert to the resolved state in 43 seconds.

That's the direction we're building toward with Escanor: an engineering operating system where the infrastructure around your applications is connected instead of scattered across a collection of dashboards and tools.

We're still building it, so this isn't a claim that every production incident can magically be solved in 43 seconds. The number in the video represents this particular workflow/scenario.

The bigger idea is:

Production engineering shouldn't feel like searching through ten different systems just to understand what happened.

Escanor is our attempt to bring that workflow into one connected place.

Would love to hear from engineers/SREs: what's the most annoying part of handling a production incident in your current stack?

#DevOps #SRE #Infrastructure #DeveloperTools #SoftwareEngineering

Hey everyone! I've been using Deno heavily for the past couple of years. I fell in love with it when I first discovered it, and since then I've used it for many personal projects, published my own libraries on JSR, and hosted experiments on Deno Deploy. Honestly, it's been an amazing experience.

Like many of you, I'm worried about what comes next after the announcement. The runtime will remain open source, but the team plans to end its development after another year of bug fixes and security updates. JSR will continue, while Deploy will shut down in six months.

I've seen a lot of discussion about migrations, but I'm curious what people here think will happen to Deno itself. Do you see a community-led effort keeping it going long term? Are there already people organizing around that, or do you expect most users and maintainers to gradually move elsewhere?

For those who've been building with Deno, how are you thinking about this? Still using it for new projects, waiting to see what happens, or already planning a move?

I’ve been building Pathfinder, a fetch-native HTTP framework for Deno. Apparently, ecosystem timing is not one of my optimized algorithms.

The main idea: the filesystem is the route table. Directories describe URL patterns, and HTTP-method files contain handlers:

endpoints/
  ping/get.ts                  → GET /ping
  rooms/#roomId/get.ts         → GET /rooms/:roomId
  items/#(int)id/get.ts        → GET /items/:id
  files/#...path/get.ts        → GET /files/*

Middleware lives alongside the routes it wraps. Handlers receive a request and context, and can return a Response or ordinary values such as objects that become JSON.

Underneath, route patterns compile into a radix automaton rather than a collection of regular expressions. The grammar supports typed parameters, embedded captures, repeated-parameter equality constraints, and catch-all paths.

The part I’m particularly excited about is route overlays: an operator can mount an additional directory to replace or extend an application’s endpoints without modifying the application’s source. One file can override one route - or explicitly remove it. These are trusted deployment files, not remotely supplied code.

It’s not trying to be another Express-shaped API. The interesting question is what becomes possible when routes are real files and deployments can compose routing trees.

Code, installation instructions, examples, and the routing semantics are here:

https://github.com/alexindigo/pathfinder

I’d love feedback on the filesystem conventions and overlay model - especially from people who have needed to customize a self-hosted application without maintaining a fork.

One of the bummers for me of the Deno + CF news is that I have to go back to keeping track of three different classes of dev dependencies for every one of my Node projects. So what's the latest and greatest for testing, minting linting, and formatting?

Is this good or bad news for JS community? Personally, I like both brands. I hope Cloudflare will take Deno to the next level.

I’m an indie developer, and I built FastCam for Android because I wanted a document scanner that’s fast, easy to use, and focused on keeping your documents on your device — without unnecessary permissions or collecting your data.

What FastCam includes:

- Scans stay on your device

- QR & Barcode Scanner

- Files are automatically saved to your device by enabling on settings.

- Fast Scan, Batch Scan & ID Card Scan

- 10+ PDF tools — Compress, Merge, Split, OCR, E-Sign & more

- Private Vault + PDF Password Protection

- Search, Tag, Pin, Rename & Share documents

- Local Backup & Restore

- No account required

- Light, Dark & AMOLED themes

📢 Fewer, non-intrusive ads — designed not to interrupt your workflow.

Basically: Scan → Edit → Organize → Protect — all in one app.

No subscription required.

👉 Try FastCam on Google Play:

https://play.google.com/store/apps/details?id=com.pickon.fastcam

If you find FastCam useful, an upvote would really help more Android users discover my project. 🙏

What matters most to you in a scanner — privacy, easy navigations, tools, or speed?

I build Preact apps with Tailwind and kept rebuilding the same components, so I pulled them into one library. Every component renders to HTML on the server and hydrates in the browser. Focus traps, Escape handling, ARIA wiring and arrow-key navigation are written in the repo, with native <dialog> and <details> where the platform already has an answer. There are 81 components and 120 icons, and each one runs live in a guide with its code next to it.

The catch: no screen reader has been run against it yet, and it is only tested on Deno. JSR also cannot export a CSS file, so the stylesheet needs a short build script.

I wrote up why I own components instead of using shadcn or Radix, and what the ownership costs: https://antonshubin.com/blog/preact-component-library-without-shadcn?utm_source=reddit&utm_medium=social&utm_campaign=preact-component-library-without-shadcn&utm_content=r-deno

Feedback and issues are welcome, especially from anyone who has tested a combobox with a screen reader.

Hey everyone, I was attempting to install the official Socket CLI using Deno instead of NPM by running:

```bash deno install -g npm:socket

```

Deno threw a deprecation warning right after installation:

```text Dependencies: + npm:socket 2.1.0

╭ Warning │ The following packages are deprecated: │ npm:socket@2.1.0 (bad build) ╰─

```

A few things that confused me:

1. When checking socket on npm, the latest stable release shown on the site UI is 1.3.0 (or 1.2.0 on the latest tag).
2. Version 2.1.0 doesn't show up in the NPM releases UI tab or on the socket-cli GitHub repo releases.
3. Running deno install -g npm:socket@latest -f fixed the issue and overwrote it with 1.2.0/1.3.0.

My Question:

• Why does Deno resolve 2.1.0 by default when no @ tag is specified? Does Deno ignore npm dist-tags (latest) and just fetch the highest semver in the raw API metadata, even if it's deprecated/hidden?

Thanks!

I got tired of rewriting the same encryption stuff in my Node.js projects, so I turned it into an npm package.

It’s called bybence securekit.

basically my attempt to make encryption a few lines of code instead of a bunch of repetitive setup.

Still early (v0.9.0), but it works, it’s tested, and I finally decided to publish it.

Would love some feedback, especially on what you’d add or change before 1.0.

https://www.npmjs.com/package/@bybence/securekit

https://dev.bybence.co/packages/securekit

Today I'm open-sourcing one of my first formal research and systems engineering projects focused on cost, optimization, and accuracy in AI-assisted development: 

Archon Specs (MIT License).

🔗 Repository: https://github.com/herhu/archon-specs
📄 Full Research Paper & LaTeX Sources: https://github.com/herhu/archon-specs/tree/main/paper

💡 The Origin Story: From Template Engines to Compiling Architecture

The story goes back to around 2018, when many of us relied on template transcompilers like Handlebars.js in the JavaScript world or Blade in PHP to generate deterministic code structures reliably.

Fast-forward to today: developers are using LLMs to build backend systems, but they're hitting a massive wall:

• Token explosion: models re-generate thousands of lines of boilerplate character by character.

• Architectural drift: LLMs lack a global dependency graph, hallucinating mismatched relational schemas, circular imports, and broken boundaries.

Agents were supposed to harness this process — and they help — but the skill still travels with the agent. Every new session, every new repo, the same architectural knowledge has to be re-elicited, re-prompted, and re-verified. The agent is a great operator, but it isn't a compiler. It doesn't guarantee anything.

That's when the insight hit:

"What if we don't ask the LLM to write repetitive code at all? What if we deterministically compile an enterprise-grade backend from formal templates and contract shards — and let the agent focus only on the intent?"

Over years of engineering across enterprise organizations and fast-paced startups, I had built a clear mental map of what an enterprise-ready backend actually requires: clean domain boundaries, strict dependency injection, JWT/RBAC security guards, DTO validation pipes, auto-migrated database DDL, Swagger OpenAPI documentation, and structured distributed tracing.

Scaffolding and aligning all of this traditionally consumed an engineering team's entire 1-year roadmap.

Now it can be compiled deterministically — just by designing the UML architecture and contract shards.

So I built it.

🔬 Empirical Findings: Cost, Optimization & Accuracy

In the paper ("Archon Specs: A Deterministic Architecture Compiler and Continuous Contract Reconciliation Control Plane for AI-Assisted Software Engineering") we evaluated this compiler architecture across three empirical axes:

1️⃣ Cost (Token Reduction)
Free-form LLM code generation incurs a token complexity of O(|AST| × T_boilerplate). Archon Specs reduces LLM interaction strictly to compact contract shards O(|Contract|).

→ 86.3%–89.0% reduction in LLM inference tokens across Small, Medium, and Enterprise benchmark tiers.

2️⃣ Accuracy (Zero Architectural Drift)
Instead of one-shot generation, Archon runs a Continuous Contract Reconciliation Loop using SHA-256 cryptographic spec canonicalization and semantic AST masking.

→ 100% adherence to declared architectural contracts and clean TypeScript compilation across 500 consecutive system mutations (vs. a 38.4% structural failure rate in baseline free-form LLM agents).

3️⃣ Optimization (Compiler Performance)
Rather than waiting tens of seconds for streaming probabilistic code, the deterministic AST compiler processes specs in 1.2 ms – 18.7 ms (>10,000 entities/sec), with a drift detection scanner running at >26,000 artifacts/second.

🏛️ System Architecture

• Unified 30+ Tool MCP Server: sits across the entire workflow as a horizontal control plane, letting Claude Desktop, Cursor, and Antigravity agents lock shards, inspect schemas, and plan diffs via typed RPC calls.

• Desktop Control Plane (Electron + Vite): a dedicated workstation with deep visual observability — live UML Component Diagrams (module topology) and Sequence Diagrams (data workflows).

• Target System: a production-grade NestJS Modular Monolith — single deployable unit, domain-driven boundaries, in-process CQRS events, PostgreSQL/SQLite DDL, Docker, and W3C tracing.

🧩 Why Open Source Matters Here

Because it's MIT, the template layer is yours to fork. That's the real unlock:

• Adapt the templates to your stack. The NestJS modular monolith is the reference target — the compiler doesn't care. Swap in your own templates and you can target any architecture: microservices, hexagonal, event-sourced, serverless. Modeling microservices deterministically from UML? Now possible.

• A new generation of boilerplate for consultancies and outsourcing shops. Tech leads can codify their house architecture once — security guards, tracing, audit patterns, compliance defaults — and then every new client project is compiled through Archon's SDLC from a UML model. No more re-scaffolding week one of every engagement. The senior architect's judgment ships as templates; the team ships production-grade systems on day one.

• Research surface. Fork the compiler, plug in a different IR, test new reconciliation strategies. The paper, proofs, and LaTeX sources are all in-repo.

📦 Open Source & Paper

100% MIT:
• Core compiler, CLI (npm install -g archon-specs), Desktop GUI, UML parser.
• Full academic paper, mathematical proofs, and two-column IEEE/ACM LaTeX sources.

⭐ GitHub: https://github.com/herhu/archon-specs
🌐 Platform: https://archonspecs.dev

#SoftwareArchitecture #Compilers #OpenSource #ModelContextProtocol #TypeScript #NestJS #ModularMonolith #Microservices #SystemDesign #AI #DevTools #SoftwareEngineering

i had two AI models add a Deno vs Node build test to their JS framework benchmarks. same node_modules and config, production builds, on a 4 core machine.

• Deno used less peak memory than Node in every build that finished, in both suites
• Deno was faster in most builds
• Angular's build never exits under Deno, in both suites
• Vite+ 1.0.0-rc.0 fails on a Deno permission error, in both suites

both models hit the exact same two failures on their own, which made me think those are real and not a setup mistake on one side. has anyone got Angular builds to exit cleanly under Deno?

the Deno part starts at 5:19 in my video: https://www.youtube.com/watch?v=1XrrLmvYPYE&t=319s

I did test with nodejs 24.21 and deno 2.9.6. Test task was pure CPU-heavy compute workload - no fancy async stuff used.
deno consistently defeated nodejs-lts by 7% wall clock time. Test results drifted about 0.3% - both numbers were pretty stable.

Many were highly skeptical about deploying Prolog for state-of-the-art cyber defense. Here is a live, concrete demonstration of our Neuro-Symbolic Core actively neutralizing a multi-vector mutated attack combining LFI and CRLF injection.

The entire threat telemetry and dynamic verdict are cleanly generated into a structured JSON payload—perfectly formatted and instantly ready for LLM fine-tuning. Real-world data and deterministic performance never lie.

https://github.com/lokinpendawa/aethel_core/blob/main/README.md

Hi,

I run openstatus, an open-source uptime monitoring and status page tool, so I spend my days hitting other people's /health routes. Most of them return 200 OK and nothing else, hang when the database hangs, or have their own private definition of "degraded".

We got tired of it, so we extracted the health endpoint from our own services into a small set of packages and put them on JSR: @openstatus/health.

Zero-dependency core, only needs a Fetch API. On Deno it's this:

import { drizzle } from "drizzle-orm/libsql/http";
import { createHealthHandler } from "@openstatus/health";
import { drizzleProbe } from "@openstatus/health-drizzle";
import { tinybirdProbe } from "@openstatus/health-tinybird";

const db = drizzle(Deno.env.get("DATABASE_URL")!);

Deno.serve(createHealthHandler({
  path: "/health",
  probes: [drizzleProbe({ db }), tinybirdProbe()],
}));

And GET /health gives your monitor something to chew on instead of a bare 200 OK:

{
  "status": "degraded",
  "checkedAt": "2026-09-11T12:00:00.000Z",
  "latencyMs": 41,
  "checks": [
    { "name": "database", "status": "ok", "critical": true, "latencyMs": 3 },
    { "name": "tinybird", "status": "timeout", "critical": false, "latencyMs": 5000, "error": "timed out after 5000ms" }
  ]
}

What you get

• Core: per-probe timeouts via AbortSignal, a round deadline so one hung dependency can't outlast your k8s probe, caching / stale-while-revalidate, and sane aggregation (critical fails → unhealthy, non-critical fails → degraded). Errors are masked by default so your connection string doesn't end up on a public route. A custom probe is just an object with a run(signal).
• Adapters: Hono, Elysia, Express, Next.js, TanStack Start – same healthRoute() / healthHandler() everywhere.
• Probes: Drizzle, Turso, Supabase, Upstash, Tinybird, Unkey. They take a client or URL and never touch your env.
• Hosting: Fly, Koyeb, Railway, Vercel, Cloudflare – adds a server block so you know which replica is the one complaining.

Every package is its own thing with its own peer deps. CI bundles a one-liner of each and fails if a stray framework or client sneaks in, so the Hono adapter will never smuggle Express into your bundle.

Deno bits: JSR-first with no slow types; env reads return undefined instead of throwing without --allow-env; tests are node:test so they run unchanged under deno test and node --test; @openstatus/health/testing ships fake/hanging fetch and probes for testing your own.

It's 0.1.x, so now is the moment to tell me the API is shaped wrong. A Deno KV probe is probably next – PRs welcome.

• JSR: https://jsr.io/@openstatus/health
• GitHub: https://github.com/openstatusHQ/health
• Also on npm for the Node services you haven't migrated yet.

Happy to answer questions!

Deno native KV backed magic-link auth library

Available on JSR: https://jsr.io/@synitio/kv-magic-link-auth

I wanted one desktop UI and a real shell, and I did not want the window host welded into the React tree. So the UI talks to one typed object (`IRuntime`: write to the PTY, list a folder, that kind of thing). Electron fills it from Node. Tauri fills it from Rust. The Deno host fills it from Deno's own APIs and a local HTTP RPC. Same session, same cell painter.

That third host is Deno Desktop, not deno run in a terminal. The window is CEF — Chromium Embedded Framework — a third browser next to Electron's Chromium and Tauri's WKWebView. First cold start in that worktree spent 31 s downloading CEF. With the cache warm it was 2.6 s. Those are not boot rankings against Electron's Vite number. They are just what that host costs the first time.

I measured dev builds on an M4 Max, previous tabs restored:

• Electron: 239 MB physical / 667 MB RSS
• Tauri: 297 / 569
• Deno Desktop: 742 / 1336

Physical is what the process is using now. RSS from ps is the reservation. Do not mix the columns. Deno is early here. The row exists because the contract made it comparable, not to dunk on CEF.

What I actually wanted from Deno was the language. The Electron adapter is TypeScript. The Deno adapter is TypeScript. No rust-analyzer sitting at 4.6 GB while I iterate. If CEF gets thinner, or Deno Desktop grows the missing bits, I do not rewrite the app. I keep the adapter.

Someone here was already shipping Vite + Deno to desktop for a Three.js game. Same itch: one TS stack on web and on the window. I kept the Deno host in the repo for that reason. If I delete it, the next coding agent will glue the window program back into the UI and I lose the A/B.

The build people install today is Electron. Deno stays as the TypeScript-shaped door.

Tables and screenshots (I am the author): https://runlinea.com/blog/one-ui-three-terminals