public digest · 5 picks
ERP in PHP, .NET orchestration, and five embedded picks worth your time
Five repos this week that span a pretty wide range — from PHP ERP systems targeting small businesses to C libraries running on microcontrollers with 64KB of RAM. The common thread, if there is one, is that each of these is trying to solve a real infrastructure problem that most teams eventually hit: how do you orchestrate a distributed app locally, how do you handle USB on bare metal, how do you manage game servers without paying for a proprietary panel?
None of these are perfect. We'll tell you where the rough edges are so you can decide whether the trade-offs work for your situation before you spend a weekend on it.
// pick 1 of 5
AureusERP is a Laravel 13 + FilamentPHP 5 based ERP system targeting SMEs, covering accounting, inventory, HR, CRM, and project management through an installable plugin architecture. It's built by Webkul (makers of Bagisto) and is MIT licensed. Aimed at PHP shops that want a self-hosted Odoo alternative they can actually read and modify.
If you've ever looked at Odoo and thought 'I'd use this if I could actually read and modify the source without a PhD in Odoo internals,' AureusERP is the answer. It's built by Webkul — the team behind Bagisto — on a stack any Laravel developer will recognize: Laravel 13, Filament 5, Livewire 4, Tailwind 4. The plugin architecture is the real story here: each module ships with its own migrations, seeders, and artisan install/uninstall commands, so you can run just invoicing without deploying accounting, HR, and CRM alongside it. CI includes Pest, Playwright E2E, and a translations check — more discipline than most open-source ERP projects bother with.
What to know going in: Filament 5 is still in beta/RC territory, so the entire UI layer sits on an unstable dependency — expect to chase breaking changes. The multi-language story is thin (real translations exist only for English and Arabic). PostgreSQL isn't supported, which will block some production deployments. And there's no mention of multi-company support, which is often non-negotiable for SMEs with subsidiaries. This is promising but not yet a drop-in Odoo replacement for complex setups.
View on GitHub →
// pick 2 of 5
Aspire is Microsoft's opinionated orchestration layer for .NET-centric distributed applications, letting you define your entire service graph (APIs, frontends, databases, caches) in code and run it locally with built-in OpenTelemetry. It recently expanded to support TypeScript, Python, Go, Java, and Rust apphosts alongside C#. The target audience is .NET teams building microservices who want a Docker Compose replacement that carries the same definition into cloud deployment.
Aspire's core pitch — define your whole service graph in code, run it locally with traces and metrics wired up automatically, and carry that same definition toward deployment — holds up in practice for .NET teams. The OpenTelemetry integration is the strongest part: you get distributed traces and structured logs in the local dashboard without manually initializing SDKs in each service. The recent polyglot apphost additions (TypeScript, Python, Go, Java, Rust) are genuinely useful for mixed-language shops that don't want to write C# just to describe their infrastructure.
The CI is unusually mature: quarantine workflows for flaky tests, automated issue creation when flakiness is detected, and outerloop runsheets. Someone put real thought into keeping the test suite honest.
What to know going in: non-.NET language SDKs are clearly second-class right now — the TypeScript SDK is auto-generated and the others are still in early validation. Deployment is heavily Azure-weighted; targeting AWS or self-hosted Kubernetes means writing your own deployment provider against docs that are still sparse. The DCP binary is a runtime dependency from a separate repo and acts as a black box for anyone trying to understand what's actually happening during local orchestration.
View on GitHub →
// pick 3 of 5
Zephyr is a Linux Foundation RTOS targeting microcontrollers and small embedded systems, supporting ARM, RISC-V, x86, ARC, Xtensa, MIPS, and more. It's backed by major industry players (Nordic, NXP, Intel) and is the serious open-source alternative to FreeRTOS for anyone who needs real hardware abstraction, proper subsystems, and a real build system. Aimed at embedded developers building IoT, wearables, or industrial devices.
Zephyr is what you reach for when FreeRTOS starts feeling too bare and you need real subsystems — networking, Bluetooth, USB, filesystem, power management — with hardware abstraction that actually abstracts. The devicetree + Kconfig model is the right architecture for this: hardware description stays separate from application configuration, vendor board files don't pollute your app, and out-of-tree modules can ship drivers without forking the kernel. Nordic, NXP, and Intel all upstream their support directly, which means the nRF52 and STM32 ecosystems are genuinely well-maintained rather than community-maintained-and-hoping.
CI is serious: Twister runs thousands of tests across emulated and real targets, bsim handles Bluetooth simulation at scale, and per-PR footprint tracking catches size regressions before they merge.
What to know going in: the getting-started experience is rough. West, CMake, Python virtualenv, the Zephyr SDK, and Kconfig all have to be correctly set up before you see a blinking LED, and diagnosing a broken environment often requires understanding all of them simultaneously. Driver quality varies significantly outside the popular targets. API deprecations happen on an aggressive schedule, so application code that isn't actively tracked against main will break. This is a serious RTOS for serious embedded work — the learning curve reflects that.
View on GitHub →
// pick 4 of 5
TinyUSB is a USB host/device stack for microcontrollers, covering 50+ MCU families from STM32 to RP2040 to ESP32. It handles the full USB protocol stack in C with zero dynamic allocation, making it suitable for constrained embedded targets. If you need to make a microcontroller appear as a HID device, CDC serial port, USB mass storage drive, or audio device, this is the go-to library.
TinyUSB's defining characteristic is that it does zero dynamic allocation — every buffer is statically declared at compile time. In constrained embedded contexts this isn't just a nice property, it's often a requirement: deterministic memory usage, no heap fragmentation, no possibility of a USB interrupt corrupting your stack mid-transfer. The ISR deferral design reinforces this: interrupts push events into a queue and all protocol processing runs in task context, which makes it genuinely safe alongside FreeRTOS or a bare-metal superloop.
MCU coverage is exceptional — DWC2, FSDEV, EHCI, OHCI, MUSB, and a dozen vendor-specific controllers are all present with real implementations. CI covers GCC, Clang, and IAR build matrices, PVS-Studio static analysis, OSS-Fuzz fuzzing, and hardware-in-loop tests. For a C embedded library this is above average.
What to know going in: the host stack is significantly less mature than the device stack — hub support has known gaps in multi-TT scenarios. USB Audio (UAC2) and Video (UVC) are incomplete; isochronous transfer beyond basic audio will require substantial work. The Power Delivery support is explicitly experimental and STM32G4-only, despite being listed as a feature. Configuration is entirely through a tusb_config.h header with compile-time defines — no Kconfig, no CMake options, and you have to read source to discover what all the knobs are.
View on GitHub →
// pick 5 of 5
Pterodactyl is a game server hosting panel that wraps game servers in Docker containers and provides a web UI for managing them. It consists of this PHP/Laravel panel repo plus a separate Go daemon (Wings) that runs on each host node. Primarily used by game hosting providers and communities who want a self-hosted alternative to proprietary panels.
Pterodactyl's architecture decision to keep the PHP panel completely separated from the Wings Go daemon — communicating only through an authenticated remote API — means the web app never touches Docker directly. That's the right call and it shows throughout the codebase. The Egg system for defining game server configurations is clever: JSON-based configs that describe startup commands, environment variables, and install scripts, with import/export built in. That's what makes the community egg ecosystem viable and why hosting providers actually use this in production.
The permission model is reasonably thought-through: subuser scopes per server, explicit permission sets on API keys, TOTP 2FA. Active CI with PHPCSFixer, ESLint, and TypeScript on the frontend suggests ongoing maintenance discipline.
What to know going in: the admin panel is Blade while the client area is React/TypeScript — two completely different frontend paradigms in one codebase, which makes contributing feel different depending on which area you're touching. Installation is genuinely multi-step: nginx config, artisan commands, cron, queue workers, then Wings separately on each node. No official single-command setup exists. The last stable release tag is from 2022 while development continues on a branch, creating friction between what's documented and what's current. The repository pattern with explicit interfaces per model adds boilerplate but Eloquent gets used directly in many services anyway, so the abstraction doesn't consistently deliver what it promises.
View on GitHub →
That's the week. If you want these picks in your inbox before they hit the site, there's an email signup at the bottom of the page — no noise, just the weekly list.
Get this in your inbox →