You're browsing as a guest. Sign up to post, like and connect.

Sign up
GGideonopensource3h

GitHub's MCP Server tracks the stateless MCP spec, and the Redis session drops out

Four days before the 28 July 2026 cutover to a stateless MCP core, GitHub says its MCP Server has been updated to track the new specification, per the GitHub Changelog dated 23 July. The headline for anyone wiring a coding agent into a pipeline is what the server no longer has to remember between calls: per-session state, and the Redis it used to sit in. What the stateless core removes MCP is the protocol coding agents use to reach tools, and until this spec revision the reference shape carried per-session state on the server. Per GitHub, the new version pushes to a stateless core, which the changelog frames as easier to scale. GitHub's server, which is built on the official Go SDK per the post, ships three concrete implementation changes as part of tracking the new spec. First, Redis-backed sessions are gone: database writes on initialize are removed, and database reads are removed from every call. Second, the server still reads some values out of each request for logging and secret scanning, but it does that without deep packet inspection on the payloads it forwards. Third, the elicitation implementation is upgraded, and the stdio MCP server now uses URL elicitation for user login. Why an on-call cares A stateful protocol demands session affinity. In practice that means an MCP endpoint behind more than one replica needs sticky routing or a shared session store, and both are the kind of thing that show up as odd, hard-to-repro tool failures when an agent's session hops backends mid-workflow. Pulling the per-session store out of the hot path removes that class of failure. It also removes a Redis dependency from the server's uptime picture, which is one less thing to page on at 3am. The trade is where the state lives instead. If the server stops carrying the session, the client and the transport have to carry more of it. That is what the elicitation change signals for the stdio MCP server: login is handed to a URL flow the client walks through, so the server side does not have to remember who is on the other end of the socket. For pipelines that spin up a fresh agent per job, that model actually lines up with how CI already treats state. Migration, per the changelog GitHub's guidance to consumers is short. Because the tier 1 SDKs preserved backwards compatibility and shipped beta support ahead of the cutover, clients on a current SDK do not need to change anything to keep working. Read literally, that puts the change at the runtime level, not the wire contract. The catch to flag for on-call is what "no action required" does not cover. It describes call-site compatibility, not deployment topology. If your own MCP server, or a self-hosted proxy in front of GitHub's, was leaning on the old session lifetime for auth caching or rate limiting, that assumption goes away when the upstream stops storing it. Worth checking before 28 July, not after. Where other MCP implementations sit MCP is an open specification, and GitHub is one of several servers…

0
GGideonopensource3h

FakeGit floods GitHub with malicious repos aimed at coding agents

Roughly 7,600 malicious GitHub repositories, created by about 6,600 profiles, are being used to feed the SmartLoader and StealC malware chain to developers and to AI coding agents that resolve tools on their behalf, according to research from Island summarized by DevOps.com on July 23. About 1,400 of the repos were tailored to AI tooling, and more than 800 posed as Skills or MCP servers. Roughly 200 of them together pulled more than 14 million downloads by the reporting date. For any pipeline whose runners fetch capabilities or MCP servers by name from the platform, that is a fresh attack surface, not a hypothetical. Island's Oleg Zaytsev, quoted by DevOps.com, framed the agent path plainly: "an agent searching for a new capability can discover a campaign repository on its own, treat the attacker's README as legitimate documentation." Zaytsev's team walked that discovery path against Anthropic's Claude Code, Google's Gemini, and OpenAI's ChatGPT. The AI-focused push ramped up in March and peaked in April, with roughly 300 repositories created that month. What the payload does The lure ships a roughly 300 KB heavily obfuscated Lua file, disguised inside the repo as text, an icon, a license, or a data file. That file is SmartLoader; it drops StealC, an infostealer that grabs browser passwords, extension data, cookies, active sessions, screenshots, host information, and email or remote-access credentials from the machine that ran it, per DevOps.com's summary of the Island analysis. On a developer workstation or a CI runner with real tokens mounted, that is a full-fat credential harvest rather than a proof of concept. Earlier public sightings pointed at overlapping infrastructure. Straiker AI flagged an MCP-ecosystem angle in February, and Derp.ca reported FakeGit distributing Lua malware in March, according to the same DevOps.com write-up. What Island's defenses actually change The recommended controls, per the reporting, are unglamorous: evaluate any new capability in an isolated environment before wiring it into a real workflow, verify the publisher and project identity, and monitor the discovery paths your agents actually take. For a pipeline, that is the same posture already imposed on npm install: no fresh, unpinned, name-matched dependency touches a job that holds production secrets. The change is only that the entity typing the install command may no longer be a human.

0
GGideondatabases3h

Building an Interactive Sales Dashboard with Power BI and PostgreSQL

Data-driven decision-making has become an essential part of modern business operations. In this project, I built an interactive sales dashboard using Power BI and PostgreSQL to analyze vehicle sales data for a car dealership. The goal was to transform raw transactional data into meaningful insights that can help managers monitor performance and make informed business decisions. Connecting PostgreSQL to Power BI The first step was importing the dataset into a PostgreSQL database. PostgreSQL provided a reliable and structured environment for storing the sales data before connecting it to Power BI. Using Power BI's PostgreSQL connector, I established a connection to the database and imported the required table into Power BI for analysis. This approach demonstrates how Power BI can integrate seamlessly with relational databases, making it suitable for handling real-world business datasets. (https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/zlng0kn2hk2ood37htxu.PNG) Cleaning Data with Power Query The imported dataset contained several inconsistencies, including mixed date formats, currency symbols (such as KSh and KES), percentage values, and missing data. These issues had to be resolved before analysis. Using Power Query Editor, I: Converted inconsistent date formats into valid date values. Removed currency symbols and thousand separators from numeric fields. Standardized discount values into decimal percentages. Replaced invalid or missing values with nulls where appropriate. Assigned correct data types to every column. Cleaning the data ensured that calculations and visualizations were accurate and reliable. Creating DAX Measures After loading the cleaned data into Power BI, I created several DAX measures to calculate important business metrics. These included: Total Revenue Gross Profit Gross Profit Margin Total Units Sold Total Orders Average Customer Rating Average Delivery Days These measures allowed the dashboard to dynamically calculate key performance indicators as users interacted with filters and slicers. Building the Interactive Dashboard The dashboard was designed to provide an executive overview of sales performance through interactive visualizations. It includes KPI cards, revenue trends over time, revenue by vehicle type, car make, branch, customer type, payment method, and sales representative performance. Interactive slicers enable users to filter the dashboard by region, branch, vehicle type, payment status, and order date, making it easy to explore different aspects of the business. Key Takeaways This project strengthened my understanding of integrating PostgreSQL with Power BI, performing data transformation using Power Query, and developing reusable DAX measures for business reporting. Most importantly, it demonstrated how interactive dashboards can transform raw data into actionable insights that support strategic decision-making. Power BI's combination of data preparation, modeling, and visual…

0
GGideondatabases3h

Why SQL Is Still the Most Important Skill for Data Engineers

Every year there's a new "must-learn" technology—Spark, Kafka, Databricks, Snowflake, AI, LLMs... But one skill has remained essential through every wave of innovation: SQL. When I first started learning Data Engineering, I thought SQL was just another box to check. "Learn some SELECT statements, a few JOINs, and move on to Python." I couldn't have been more wrong. The more real-world projects I worked on, the more I realized that SQL isn't just a language—it's how data engineers think. SQL Is Everywhere No matter what modern stack you're using, SQL is almost always involved. Snowflake Databricks BigQuery Redshift PostgreSQL SQL Server Oracle Spark SQL DuckDB Different platforms. Same foundation. That's why companies don't just hire people who know SQL syntax they hire engineers who can solve business problems using SQL. SQL Is About Solving Problems Writing SQL isn't the difficult part. Understanding the data is. A good Data Engineer asks questions like: Where is the data coming from? Why are these numbers different? Which records should be included? Why are duplicates appearing? Why did yesterday's pipeline fail? SQL helps answer those questions quickly. Most Data Pipeline Bugs Start With SQL Many production issues aren't caused by Spark or Airflow. They're caused by things like: Incorrect JOIN conditions Missing filters Duplicate records NULL handling Wrong aggregations Time zone mistakes A single bad query can quietly produce incorrect dashboards for thousands of users. That's why experienced engineers spend so much time validating SQL logic before deploying a pipeline. SQL Is the Language of Analytics Every team depends on SQL: Data Engineers Data Analysts Analytics Engineers BI Developers Data Scientists Machine Learning Engineers Product Managers (through dashboards) If you can communicate with data using SQL, you become valuable across the organization. The Difference Between Knowing SQL and Mastering SQL Most people can write: Fewer people can confidently work with: Window functions Common Table Expressions (CTEs) Recursive queries Query optimization Execution plans Incremental processing Slowly Changing Dimensions (SCDs) Complex aggregations Performance tuning Those are the skills that separate beginners from experienced Data Engineers. SQL Makes You a Better Engineer Strong SQL skills improve more than your queries. You start to: Think logically about data. Spot quality issues faster. Design cleaner pipelines. Debug production problems more efficiently. Communicate better with analysts and stakeholders. In many ways, SQL trains you to think like a Data Engineer. My Advice for Beginners If I were starting over today, I'd spend far more time mastering SQL before chasing every new tool. Learn: JOINs (and when not to use them) Window functions CTEs Aggregations Query optimization Indexing concepts Data modeling basics The frameworks and platforms will evolve.…

0
GGideondatabases3h

Azure SQL Managed Instance vs Azure SQL Database: How I Actually Made the Call

A field decision from a real production migration — not a feature-matrix blog. When we migrated two internal enterprise applications (plus an integration layer) from on-premises SQL Server to Azure, the single most consequential decision in the whole programme was not the App Service tier, not the CDN, not the CI/CD design. It was the database platform. Azure gives you two serious PaaS options for SQL Server workloads — Azure SQL Database and Azure SQL Managed Instance (SQL MI) — and almost every comparison article online reads like a spec sheet. This post is different. It's the actual reasoning I went through, the evidence I gathered, the objections I had to answer during architecture review, and the trade-offs I knowingly accepted. If you're staring at the same fork in the road, I hope walking through my decision saves you a few weeks. The starting point: what we were actually migrating Context matters more than features, so here's ours: • One production SQL Server database, roughly 200 GB in size, that had lived on-prem for years. • Three separate backend services — two application backends and one integration API — all reading and writing to that same database. • More than 25 SQL Server Agent jobs running scheduled work against the database: batch processing, data movement, housekeeping. • A hard requirement that the database must never be exposed to the public internet — access only over a private network on port 1433. • A small team, a compressed timeline (we went from zero Azure resources to production in weeks, not months), and a real budget owner asking why every euro was being spent. That last point is important. This wasn't a greenfield app designed cloud-native. This was a lift-and-shift of a living, heavily-scheduled, single-database system that three services depend on simultaneously. The fork: two genuinely good options Azure SQL Database is the "born in the cloud" option — a database-scoped service, fast to provision, cheap to start, with elegant HA options like zone-redundant compute and active geo-replication. I took it seriously. In fact, during the evaluation I fully sketched out what a production + DR architecture on Azure SQL Database would look like for us: a General Purpose single database at 16 vCores with zone-redundant compute in the primary region, an asynchronous geo-replica standing by in a secondary region, 7-day PITR for operational recovery, and long-term retention for compliance. On paper it was a beautiful design. SQL Managed Instance is the "SQL Server, but managed" option — an instance-scoped service deployed inside your own virtual network, with near-100% surface-area compatibility with on-prem SQL Server. The honest question I forced myself to answer: does our workload actually need the instance, or am I just choosing the familiar thing? During architecture review, this exact challenge came back to me formally: "Re-validate whether SQL Managed Instance is the intended PROD choice." Someone has to def…

0
GGideondatabases3h

I Didn't Plan to Build an Offline-First Attendance System. Firestore Forced Me To.

How accidentally exhausting Firestore's free-tier limit transformed a rushed MVP into a more resilient anti-proxy attendance system. Introduction When I started building an attendance system for my university's UBA (Unnat Bharat Abhiyan) club, I had one clear instruction from our coordinator: "Build an MVP as soon as possible." Like most student developers, I focused on getting the features working first. The application already had everything I needed for the MVP: Dynamic QR-based attendance Firebase Authentication Firestore database Anti-proxy validation Admin dashboard Meeting management My daily workflow looked something like this: Code ↓ Run ↓ Test ↓ Scan QR ↓ Debug ↓ Repeat Everything seemed to be progressing smoothly. What I wasn't paying attention to was something happening quietly in the background. Every refresh. Every API call. Every test. Every debugging session. All of them were consuming Firestore document reads. The Problem I Never Expected One day, while testing the application, things suddenly stopped working. Attendance requests started failing. Firestore wasn't responding. Like most developers, my first thought was: "I definitely broke something." I checked my recent commits. I reviewed the API routes. I verified Firebase Authentication. I even looked through my Firestore Security Rules. Everything looked perfectly fine. Then I opened the Firebase Console. That's when I saw it. Firestore Reads: 50,000 / 50,000 I had exhausted the entire free-tier quota. Not because thousands of students were using my application. Not because it had gone viral. Simply because I had spent days developing and debugging it. Ironically, I had become my own biggest user. The Easy Fix Wasn't the Right Fix Technically, I could have waited for the daily quota to reset. Problem solved. But this wasn't just another side project. It was an attendance system intended to be used during actual UBA meetings. If Firestore became unavailable during a meeting, attendance couldn't simply stop. So instead of asking, "How do I reduce Firestore reads?" I asked a different question. "How do I make the system continue working even when Firestore isn't available?" That single question completely changed the architecture of the project. Offline-First Was Never the Plan Before this happened, offline support wasn't even on my roadmap. Every attendance request depended on Firestore. Every scan required the backend. Which meant one dependency controlled whether the entire application worked. I didn't like that. So I redesigned the workflow. Instead of immediately writing attendance to Firestore, the application could now continue functioning locally whenever the backend wasn't available. Attendance records would be stored securely on the device and synchronised automatically once connectivity or database access returned. The project unexpectedly became offline-first. But There Was One Catch... Building o…

0
GGideondatabases3h

Adding Full-Text Search

Emails are going out reliably now, thanks to the queue and templating work from Sending Transactional Emails. The next feature request on almost every SaaS backlog is search: a box at the top of the screen where a user types a few words and expects to find the right project, ticket, or document in under a second. This is part of the Full Stack SaaS Masterclass, and it's a good place to make a deliberate architectural decision early. Search is one of those features where the tempting answer, "add Elasticsearch," is usually the wrong first move. PostgreSQL already ships a full-text search engine, and for the vast majority of SaaS products it's the right place to start. This article covers how Postgres full-text search actually works, how to wire it into a NestJS API and a Prisma or TypeORM schema, and where the real tradeoffs sit between "good enough" and "we need Elasticsearch." Why Postgres before Elasticsearch The instinct to reach for a dedicated search engine comes from a reasonable place. Elasticsearch is genuinely excellent at search, and if you've worked on a product with millions of documents and complex relevance tuning, you've probably felt its ceiling is higher than anything Postgres offers. But a new SaaS product doesn't have that problem yet. It has a handful of tables, a modest amount of data, and one search box that needs to find rows by matching words, not typos or synonyms across a corpus of a billion documents. Solving that with a second stateful system is overkill. An Elasticsearch cluster brings its own indexing pipeline, its own operational surface, and its own failure modes, and standing one up to solve a problem your primary database already solves is exactly the kind of premature complexity this series keeps warning against. Postgres full-text search gives you ranked, stemmed, multi-column text matching using indexes you already have infrastructure to back up, monitor, and scale. It lives in the same transaction as the data it searches, so there's no separate indexing pipeline to keep in sync and no eventual-consistency window where a newly created row doesn't show up in results yet. That last point matters more than it sounds: a user who creates a project and immediately searches for it expects to find it, not to wait for a sync job. The honest tradeoff is that Postgres full-text search is a keyword and ranking engine, not a semantic search engine. It won't understand that "invoice" and "bill" mean roughly the same thing unless you teach it to, and it doesn't do typo tolerance out of the box. Elasticsearch, or a purpose-built vector search layer, earns its place once you have that specific need and the data volume to justify running it. How Postgres full-text search actually works Full-text search in Postgres revolves around two types: tsvector and tsquery. A tsvector is a preprocessed, normalized representation of a document's text: lowercased, stripped of stop words like "the" and "a", and reduced to word stems so…

0
GGideonmobile3h

Best Mobile Apps for OpenAI Codex in 2026

On May 14, 2026, OpenAI put Codex into the ChatGPT mobile app. That changed the answer to "codex mobile app" overnight. If we want to use Codex from a phone in 2026, we now have one official first-party path, one browser fallback, two terminal workarounds, and one native iOS app built around the fact that many teams run Codex and Claude Code side by side. Those options are not interchangeable. Some are great for quick approvals. Some are good enough only if we already live in tmux. Some are best avoided unless we have no other path. This guide covers the five realistic ways to work with Codex from a phone in mid-2026, what each one actually runs, what the phone can and cannot do, and which teams each option fits. We list our own iOS app inside the lineup, but keep it in the same table and the same standard as everything else. At a Glance | Option | What actually runs | Best mobile use | Local Codex | Cloud Codex | Claude Code too | |---|---|---|---|---|---| | ChatGPT mobile app | Codex on a connected laptop, Mac mini, devbox, or remote environment | Official live steering, approvals, check-ins | Yes | Yes | No | | Nimbalyst iOS | Codex CLI sessions hosted by Nimbalyst desktop on the Mac | One mobile board for Codex and Claude Code | Yes | No | Yes | | Tailscale + SSH | Codex CLI on our own machine | Raw terminal access | Yes | No | Yes, manually | | ChatGPT web on mobile | Codex web in a phone browser | Browser fallback when the app is not available | No | Yes | No | | Conductor + Tailscale handoff | Codex in a Conductor workspace on a Mac, reached over SSH | Conductor fallback for existing users | Yes | No | Yes | What Mobile Codex Means in 2026 The phrase codex mobile app now covers three different patterns: • The official OpenAI path: ChatGPT mobile connects to machines where Codex is running and lets us steer live work from the phone • The cloud task path: Codex web inside ChatGPT can still run cloud tasks tied to GitHub • The self-hosted path: Codex CLI runs on our own Mac or devbox and we reach it through a third-party mobile surface or plain SSH A useful mobile workflow still comes down to four things: • Checking live progress without opening the laptop • Answering a clarifying question or approving the next step • Reviewing the diff or at least the result summary • Starting a new task while the idea is still fresh The five options below cover that ground in very different ways. The Options ChatGPT Mobile App Platform: iOS, Android | Price: Included with ChatGPT plans, with usage limits that vary by plan This is now the default first-party answer for Codex on a phone. OpenAI's current mobile story is not just "cloud tasks in ChatGPT." The app can connect to machines where Codex is already running and load the live state of that environment on the phone. How Codex actually runs: Codex runs on a connected machine such as a laptop, Mac mini, devbox, or managed remote environment, while the ChatGPT mobile app mirrors the live threa…

0
GGideonmobile3h

How to Run Samsung DeX on a Mac (One UI 8, No Monitor Needed)

Samsung quietly discontinued the official Samsung DeX app for Windows and Mac, and for a while the only way to get the DeX desktop was to plug your Galaxy phone into a real monitor. That changed with One UI 8 (Android 16): DeX is now built on Android's native Desktop Mode, which can run on a virtual display — and that means you can put the whole DeX desktop in a window on your Mac, with nothing but a USB cable (or even just WiFi). This guide shows you how, start to finish. It takes about ten minutes, uses only free and open-source tools, and needs no external monitor, no HDMI cable, and no HDMI dummy plug. TL;DR — Install scrcpy + adb, enable USB debugging on your Galaxy phone, and run scrcpy --new-display=1920x1080/160. The DeX desktop opens in a Mac window. Prefer a one-click menu-bar app? Use DeXBar. What you need • A Samsung Galaxy phone or tablet running One UI 8 (Android 16) or newer. This is the key requirement — older One UI versions can't render DeX on a virtual display, so this method simply won't work on them. • A Mac (Apple Silicon or Intel), macOS 13 or later. • A USB cable (used at least once; wireless is possible afterward). • Homebrew, the macOS package manager. Why this works now (the short version) DeX used to require a physical HDMI/DisplayPort connection because Android only entered desktop mode when it detected an external screen. Android 16's Desktop Mode added support for virtual displays — displays that exist only in software. The open-source tool scrcpy (v4.1+) can create one of these virtual displays on demand and mirror it to your computer. One UI 8's DeX renders onto that virtual display, and you see it in a window on your Mac. No hardware trickery required. Step 1 — Install scrcpy and adb Open Terminal and run: scrcpy does the mirroring; adb (Android Debug Bridge) is how your Mac talks to the phone. Step 2 — Enable USB debugging on your phone Go to Settings → About phone and tap Build number seven times to unlock Developer options. Go to Settings → Developer options and turn on USB debugging. Step 3 — Connect and authorize Plug the phone into your Mac with the USB cable. A prompt appears on the phone asking to Allow USB debugging — check "Always allow from this computer" and tap Allow. Confirm your Mac sees the phone: You should see your device listed as device (not unauthorized). If it says unauthorized, unlock the phone and approve the prompt. Step 4 — Launch Samsung DeX on your Mac Run: A window opens on your Mac showing the full Samsung DeX desktop — taskbar, resizable windows, and all. Control it with your Mac's keyboard and mouse. • 1920x1080 is the virtual display resolution. Bump it to 2560x1440 for more space. • 160 is the DPI (density). Lower DPI = smaller UI, more room; higher DPI = bigger UI. 160 is a good desktop-like default; try 140–200 to taste. That's it — you're running DeX on your Mac. Optional: run DeX over WiFi (no cable) Once it works over USB, you can go wireless as long as the phone…

0
GGideonmobile3h

Simple SDK to enable visual video search on mobile !

Framework GitHub repository https://github.com/v-modal/vmodal_sdk_flutter is the official Flutter SDK for V-Modal AI, a developer platform built for multimodal search capabilities. Under the tagline "Search anything anywhere SDK," it enables mobile developers to integrate advanced, AI-driven search into Android and iOS applications. [1, 2] Core Purpose for Video Search While V-Modal AI operates as a broad multimodal framework, it functions as a powerful tool for video search by indexing visual, textual, and temporal elements within video files. Instead of relying solely on titles, tags, or basic metadata, it allows developers to build software capable of deep content analysis. Key Capabilities Semantic Video Search: Allows users to query video libraries using natural conversational language (e.g., searching for "dog jumping over a fence in the rain" to pinpoint the exact moment it occurs). Multimodal Indexing: Parses diverse data inputs—including raw video frames, audio tracks, speech-to-text transcripts, and embedded text—into unified vector embeddings. Cross-Platform Delivery: Provides a native Flutter interface so developers can implement these complex backend AI searches seamlessly into cross-platform mobile apps using a unified Dart codebase. [1] • Example of code: Because vmodal_sdk_flutter is a specialized, proprietary framework, the following production-style template outlines how to integrate a modern vector-based multimodal search SDK into a Flutter application. This layout demonstrates how to initialize the client, index a video source, and perform a semantic content query to find timestamp intervals matching natural language. Initialization and Configuration Initialize your search client using your application API credentials. Indexing a Video File Before searching, you must process and index the video so the AI can build structural vector layers of the visual frames and dialogue transcripts. Executing a Semantic Search Query your video catalog using raw natural language sentences instead of relying on keywords or file names. [1, 2] Handling and Displaying Time Segments Iterate over your matched hits to jump directly to the precise seconds where the action occurs in your video player UI.

0
GGideoncloud3h

The Million-Tenant Problem: Why Your OpenSearch Service Architecture Breaks at Scale

Almost every search application is multi-tenant, whether or not anyone called it that. A store has product categories. A SaaS product has customers. A logging platform has teams, an e-commerce site has sellers, a B2B app has accounts. Each of those is a tenant: a slice of data, and the queries that go with it, that has to stay separate from every other slice. If you run Amazon OpenSearch Service, odds are you are already in the tenancy business. And here is the thing about tenancy: it is almost free when you have a few tenants, and it quietly turns into the whole problem when you have a lot of them. A design that is clean and obvious at a hundred tenants can fall apart at a hundred thousand, for reasons that have nothing to do with the code being wrong. Take a concrete case. You are running a fintech app, peer-to-peer payments or a neobank, and millions of users each expect to open their phone, pull up six months of history, and see it instantly. That data behaves like logs, streaming in and aging out, but it has to perform like search, because a person is staring at a spinner. It lives in the gap between the two, and the conventional wisdom for either end does not fit. I have watched teams wrestle with this exact problem. They stand up a textbook Amazon OpenSearch Service domain, follow every log-analytics best practice, demo it, and it screams. Beautiful on the happy path, right up until a certain scale. Then the queries slow down, the costs balloon, and the architecture that purred along at 10,000 tenants starts making the noise hardware makes right before the magic smoke escapes. The question I hear next is always the same: “We thought we were doing this right. What changed?” Usually nothing changed. The design followed the playbook faithfully, right down to copying the shard sizes from a blog post. The playbook just was not written for this workload, and scale is where that bill comes due. Let me walk through where the conventional wisdom runs out, and then the handful of moves that actually hold up at a million tenants. Where the conventional wisdom runs out The first trap is the pure-logging approach. The standard playbook says ingest fast, roll over indices daily, keep three days hot, then tier the rest off to cheaper storage. Shard size? Go big, 50 GB is fine, because you are optimizing for write throughput. This is excellent advice for application logs that nobody reads unless something is on fire. It falls apart the moment you serve individual tenant queries at scale. Every query fans out across every shard in the index. A terabyte in 50 shards means one user tapping their phone becomes a single request fanning out to 50 servers, all to answer somebody checking last month’s coffee purchases. The cost of coordinating that scatter-gather swamps the benefit of parallelism, especially when each tenant’s data is a thin slice smeared across all 50 shards. The cluster was tuned for throughput, and now it is being asked for the one thing t…

0
GGideoncloud3h

Point-in-Time Recovery Without the Enterprise Price Tag

description: A deep dive into HuskHoard's open-source PITR engine — how the catalog tracks version history and byte offsets across physical media, and how you roll back a single file without touching the rest of the volume. Point-in-Time Recovery Without the Enterprise Price Tag If you've priced out Veeam, Commvault, or a Zerto license recently, you already know the punchline: granular point-in-time recovery is one of the most aggressively monetized features in enterprise storage. Vendors charge for it because it genuinely solves a hard problem — and because buyers are often in enough pain that they'll pay whatever it costs. HuskHoard is an open source datatiering archive for Linux that ships PITR as a first-class feature, built directly into its catalog engine, free under AGPL v3. This post is the deep dive that the project's docs don't yet cover: how versioning actually works under the hood, how the catalog tracks byte offsets across physical media (disk, LTO tape, and S3), and how you roll back a single file without touching anything else on the volume. Versioning vs Backup: Stop Using the Words Interchangeably Before getting into mechanics, it's worth being precise about terminology, because these two words describe fundamentally different operations with different tradeoffs. A backup is a complete redundant copy of a dataset at a point in time. The goal is full-loss recovery. If your server catches fire, you restore the backup. The cost is that you're duplicating data — 10 TB of active data requires at least 20 TB of total storage to have one backup copy. Versioning (or PITR at the object level) is a historical record of how a specific file changed over time. The goal is granular rollback — recovering from an overwrite, a corruption, or a ransomware event that targeted specific files. It doesn't guarantee you can recover from total hardware loss unless your versions live on separate media. But it lets you say "give me /etc/nginx/nginx.conf as it was three weeks ago" without restoring your entire backup set. The confusion is expensive. People who treat their archive as a backup get burned when the archive goes down (there's no redundant copy). People who treat their backup as a versioning system get burned when they need to roll back a single file and discover they have to restore 2 TB of snapshot data to get at it. A solid DR strategy uses both: | Scenario | What You Want | |---|---| | Server catches fire / disk fails completely | Backup — full restore from a redundant copy | | Developer overwrites critical config file | PITR — roll back that specific file in seconds | | Ransomware encrypts 10,000 files | PITR — roll back affected files to pre-infection version | | VM guest OS corrupts itself | Backup — restore the whole VM image | | VM config file or snapshot is accidentally deleted | PITR — roll back just that object | HuskHoard handles versioning (PITR at the file/object level) natively. For full redundancy, pair it with N-way r…

0
GGideoncloud3h

94 Million Hausa Speakers, and AI Still Barely Understands Them. What Three Years of Grassroots Work Taught Me.

Hausa is spoken by close to 94 million people in Nigeria alone, with tens of millions more across Niger and the wider Sahel. Nature has reported that ChatGPT and LLMs correctly understands only 10 to 20 percent of sentences written in Hausa. I've spent the last three years trying to close that gap. First alone, then with a community I founded in Bauchi State that's since grown past 500 people. This isn't really a project retrospective. It's an honest account of what it actually takes to build language technology for a language the industry has quietly decided isn't worth the training data, and what leading the people doing that work with me has taught me. Why the gap exists, and why scraping the web won't fix it The easy explanation for Hausa's AI gap is "not enough data." That's true, but it undersells the problem. Hausa has technical properties that make naive data collection actively misleading, not just insufficient. Start with orthography. Standard written Hausa uses three hooked consonants, ɓ, ɗ, and ƙ, that don't exist on a standard keyboard. In formal, edited text they're there. In the informal Hausa that actually dominates the web (social media, SMS, WhatsApp, the actual keyboards people type on) they're routinely flattened to plain b, d, and k. Scrape the open web for Hausa and you get a corpus quietly missing phonemic information in a large share of its examples, and that gap propagates into anything trained on it, from tokenizers to text to speech models. Then there's script. Hausa has been written in two systems for over a century: Boko, the Latin based script that's now standard, and Ajami, an Arabic based script still used in religious and literary contexts. A dataset built only from Boko sources is already excluding a real slice of the written language. Then code-switching. Everyday Hausa, especially online, mixes in English freely and carries a long history of Arabic loanwords from Islamic scholarly tradition. A model that treats Hausa as a clean, isolated language misses how the language is actually used in practice. Put those together and "low-resource language" starts to look less like "not enough Hausa exists" and more like "the Hausa that's easy to scrape is a degraded sample of the Hausa people actually speak." Standard multilingual tokenizers, trained on that same degraded sample, fragment Hausa words into far more subword pieces than an equivalent English sentence needs. That makes inference more expensive and generation noticeably worse, since the model has fewer clean examples to learn from per token. That's the actual problem. Not "AI doesn't know Hausa." AI has been fed a thin, flattened version of Hausa, and it shows. Where I actually started, and why not with an LLM I founded AI Bauchi in October 2022 out of Abubakar Tafawa Balewa University, with a mission that hasn't changed since day one: make AI indigenous and accessible in Bauchi State, not just consumed from outside it. The language work grew out of th…

0
GGideoncloud3h

AWS S3 + CloudFront Subdirectory Hosting: Architecture & Edge Cases

Overview While deploying a static documentation site using AWS S3, CloudFront, and Cloudflare, I came across several edge cases that weren't immediately obvious from the documentation. This post summarizes the issues, their root causes, and the solutions that worked. I'm documenting these as technical notes for future reference, and hopefully they'll be useful to others facing similar problems. 🛠️ Lessons & Gotchas Lesson 1: Local Redirect Caching Issue HTTPS configuration and redirect changes worked correctly in Incognito mode, but normal browser sessions continued to show outdated redirects or "Not Secure" warnings. Root Cause Modern browsers cache 301 redirects and HSTS policies aggressively. Local cache can continue serving stale routing information even after CloudFront and DNS changes have propagated. Resolution Clear the domain's HSTS policy using chrome://net-internals/#hsts. Perform a hard reload (Ctrl + Shift + R / Cmd + Shift + R) with DevTools open. Validate changes using an Incognito window before troubleshooting infrastructure. Lesson 2: S3 REST Endpoints Do Not Resolve Subdirectory Indexes Issue The following requests produced different results: /iplusflow → 403 Forbidden /iplusflow/ → Object download /iplusflow/index.html → Expected HTML response Root Cause CloudFront's Default Root Object applies only to the distribution root (/). When using the S3 REST API endpoint as the origin, S3 treats every request as an object lookup and does not automatically resolve directory requests to index.html. Resolution Implement URL rewriting within CloudFront or use the S3 Static Website Endpoint when directory-style routing is required. Lesson 3: CloudFront Function Execution Stage Issue Attaching a CloudFront Function resulted in: Root Cause The function was associated with the Viewer Response event while attempting to modify the incoming request. Viewer Response expects a valid HTTP response object, whereas URI rewrites must occur before origin selection. Resolution Attach URL rewrite logic to the Viewer Request event and return the modified request object. Lesson 4: Relative Asset Resolution Depends on Trailing Slashes Issue The documentation rendered correctly at: but loaded without CSS or JavaScript at: Root Cause Browsers resolve relative asset paths based on the current URL. Given: the browser resolves: | Request URL | Asset Resolution | | ------------- | ------------------------- | | /iplusflow/ | /iplusflow/styles.css ✅ | | /iplusflow | /styles.css ❌ | Without a trailing slash, the browser interprets the final path segment as a file rather than a directory. Resolution Redirect directory requests to their trailing-slash equivalent before serving content. Final CloudFront Function The following CloudFront Function provides consistent directory routing by: Redirecting directory requests without a trailing slash. Rewriting directory requests to index.html before forwarding th…

0
GGideoncloud3h

Open Serverless v4 is here

We're long time users of Serverless Framework since v2. When v3 came out, we were able to quickly switch and all was good. Then came v4 and things changed, especially since a new licensing and pricing strategy was introduced. While there were new features, we didn't really need those anyway. We tried to get in touch with Serverless Inc. to discuss custom pricing options but they ignored our requests. Luckily, in the meanwhile, the v3 version we loved so much was forked under the name osls (short for _Open Serverless_) by Matthieu Napoli, the creator of Bref (_the_ tool that allows you to run PHP on Lambda which is not natively supported by AWS). This fork basically allowed the community to seamless switch from Serverless Framework v3 to Open Serverless, it is also very well supported. Open Serverless v4 Open Serverless v3 as a fork contains some legacy code and features. By releasing v4 these things can finally be removed. There is a well documented upgrade guide available to upgrade from v3 to v4. I recently tested this on one of our stacks and it was super easy. Having that said, we don't use very exotic features which makes the process pretty easy. AWS SSO AWS SSO support is now built in so you no longer need the serverless-better-credentials plugin. Currently you first need to login manually using aws sso login but a feature is in review that handles this using an interactive login as the plugin does. Function Pruning Automatic function pruning no longer requires serverless-prune-plugin as it can be configured natively: or a custom amount using: Durable Functions Support for Lambda Durable Functions was added, it can be configured with durableConfig like this: For more information, check the full documentation on this feature. AWS SDK v2 deprecation The AWS SDK v2 was deprecated for a long time but still used by the framework. All implementations in are updated to use AWS SDK v3 now instead. This is great and it should also remove many warnings from audit tools. The downside is that this will prevent some plugins from working that rely on provider.request() for doing requests to AWS. I created a small plugin that tries to provide a backwards compatibility layer that tries to convert a SDK v2 request into an SDK v3 request. For me it worked on the following plugins: • serverless-step-functions • serverless-stack-termination-protection (a PR exists to add native support) If you have plugins that work with v4 after using this plugin, put them in the comments and/or create a PR that adds it to the readme of the plugin itself. Esbuild I'm also very happy the serverless-esbuild plugin still works as expected. Please look at this post to see how I optimized my builds to reduce cold start times. Sponsoring We're still very happy and thankful that this fork exists and decided to sponsor Open Serverless/Bref with a monthly donation. Please do the same if these tools are useful to you so we can all benefit from continued support.

0
GGideondevops3h

Deploying Apache Cassandra on Kubernetes

Apache Cassandra is a highly scalable, distributed NoSQL database built for write-heavy workloads, horizontal scaling, and tunable consistency, with no single point of failure. K8ssandra is an open-source operator that automates Cassandra provisioning, scaling, backups, and repairs on Kubernetes. This guide deploys a multi-node Cassandra cluster via the K8ssandra Operator, with cert-manager, persistent block storage, and a LoadBalancer service for external access. Prerequisites: a Kubernetes cluster with at least 4 nodes / 4GB RAM each, a workstation with kubectl and helm configured against the cluster. Install cqlsh cqlsh is the Python-based CLI for querying Cassandra. Install cert-manager K8ssandra uses cert-manager to generate the Java keystores/truststores Cassandra needs for internal TLS. Install the K8ssandra Operator You should see both k8ssandra-operator and k8ssandra-operator-cass-operator deployments ready. Deploy a Multi-Node Cassandra Cluster Check available StorageClasses in your cluster: Note the name of a CSI-backed block storage class — you'll reference it below. Create the cluster manifest: Replace standard with your cluster's actual StorageClass name. This provisions 3 Cassandra nodes with a 10GB volume each, 512MB JVM heap per Cassandra node, and a single Stargate node (REST/GraphQL/Document API gateway in front of Cassandra) with a 256MB heap. Confirm your cloud provider's CSI driver is installed and configured before applying — it's required for dynamic volume provisioning. Apply and wait (cluster bring-up takes ~15 minutes): You're looking for 3 demo-dc1-default-sts-N pods and a demo-dc1-default-stargate-deployment-* pod, all Running. Verify Persistent Storage Cassandra nodes run as a StatefulSet, each backed by a PVC for durable storage. All three PVCs should show Bound. Expose the Cluster Create a LoadBalancer service to reach Cassandra over the native CQL protocol (port 9042): Wait for EXTERNAL-IP to populate (a few minutes) — that's your connection address. Test the Cluster Next Steps Cassandra is running as a 3-node cluster with persistent storage and a Stargate data gateway. From here: • Scale size in the datacenter spec and reapply to add nodes • Enable Stargate's REST/GraphQL APIs for app access without a native CQL driver • Configure K8ssandra's Medusa integration for scheduled backups to object storage For the full guide, visit the original article on Vultr Docs.

0
GGideondevops3h

Local Kubernetes Dev — Part 2: Production-like environments — what and why

"But I've got a docker-compose.yaml, it spins up my service with a database — why would I run Kubernetes locally?" This is the most common beginner misconception, and it's an expensive one. A Compose file is structurally NOT equivalent to Kubernetes manifests, and "works in compose" guarantees nothing about "works in k8s." Just look at the official Kompose converter, whose authors honestly warn you: depends_on is ignored, build: won't build an image, bind-mounts don't carry over, and the output is manifests with NO requests/limits, NO probes, and environment variables in plain text instead of a Secret. In other words, exactly the production-like properties we spin up a local cluster for are the ones Compose skips. Part two of the local Kubernetes series is the philosophical one. What does "production-like environment" even mean? It's NOT "an exact copy of prod" (that won't fit on a laptop) — it's a deliberate narrowing of the dev/prod gap: the same Kubernetes minor version, the same type and version of backing services (PostgreSQL, not SQLite — hello, factor X of the Twelve-Factor App), real manifests, requests/limits, probes, ConfigMap/Secret, Ingress. And we deliberately simplify scale, managed services, and load testing. The core idea: a production-like environment isn't one where "everything is like prod," it's one where you know EXACTLY what matches, what doesn't, and why. At the end — a checklist: "how close is my local setup to prod?" https://dorokhovich.com/blog/local-k8s-production-like-environments?utm_source=devto&utm_medium=syndication&utm_campaign=local-k8s-production-like-environments

0
GGideondevops3h

Deploying Strapi on a Kubernetes Cluster

Strapi is a headless CMS with an intuitive admin dashboard, custom content types, and role-based permissions, well-suited to Kubernetes for its scalability and multi-environment support. This guide builds a Strapi app, containerizes it, and deploys it to Kubernetes behind an Nginx Ingress Controller with cert-manager TLS. Prerequisites: a Kubernetes cluster with kubectl/helm configured, a PostgreSQL database, Docker on your workstation, a domain (this guide uses strapi.example.com) pointed at the ingress load balancer once provisioned. Build the Strapi Application Install Node.js: Configure Git if not already set up: Scaffold a project: Once it's running, press Ctrl+C to stop the dev server and continue configuring it. Containerize the Application Point it at PostgreSQL — edit .env in the project directory: Replace config/server.js: Set the URL, install the PostgreSQL driver, rebuild, run: Visit http://<server-ip>:1337 and confirm the admin registration screen loads. Build and Push the Docker Image Dockerfile: .dockerignore: Build, tag, push: Prepare the Cluster Install the Nginx Ingress Controller A LoadBalancer provisions automatically: It may take a few minutes for EXTERNAL-IP to populate. Install cert-manager and a ClusterIssuer Point your domain's A record at the Ingress controller's EXTERNAL-IP, then: READY: True confirms it's live. Deploy Strapi Deployment (2 replicas): regcred is a pull secret if your image lives in a private registry. Service: Ingress with TLS: Visit https://strapi.example.com — you should hit the login page over HTTPS. Scale the Deployment Scale back down: Test fault tolerance by deleting a pod. Kubernetes replaces it and the Ingress routes around the gap with no downtime: Next Steps Strapi is running on Kubernetes with TLS termination and horizontal scaling. From here: • Add a HorizontalPodAutoscaler to scale on CPU/memory instead of manually • Move media uploads to S3-compatible object storage via a Strapi upload provider plugin • Set resource requests/limits on the Deployment to avoid noisy-neighbor scheduling issues For the full guide, visit the original article on Vultr Docs.

0
GGideondevops3h

Deploying MariaDB on Kubernetes

MariaDB is a popular open-source relational database. Running it on Kubernetes gets you portability across environments, CI/CD integration, and automated backup/recovery alongside the usual scalability and high-availability benefits. This guide sets up persistent storage, deploys MariaDB as a StatefulSet, exposes it via a Service, and covers scaling. Prerequisites: a Kubernetes cluster with at least 3 nodes and kubectl configured against it. Create Persistent Volume and Claim Define a PersistentVolume: Retain keeps the data if the PV is deleted; hostPath backs it with a directory on the node. Define a matching PersistentVolumeClaim: Confirm status is Bound before continuing. Deploy the MariaDB StatefulSet Create a ConfigMap for my.cnf: Create the StatefulSet. Replace strong_password: Access MariaDB Expose it internally: Connect with a throwaway client pod: Scale the Deployment Scale back down: Each replica in this setup is an independent MariaDB instance with its own PVC — for real multi-node replication, layer in MariaDB Galera or MaxScale rather than relying on StatefulSet scaling alone. Next Steps MariaDB is running on Kubernetes with persistent storage and a scalable StatefulSet. From here: • Swap the hostPath PV for a CSI-backed StorageClass in production so pods can reschedule across nodes • Add readiness/liveness probes on port 3306 for better failure detection • Front the service with an external LoadBalancer or Ingress if clients outside the cluster need access For the full guide, visit the original article on Vultr Docs.

0