标签：#dev

LocalAI is an open-source platform for running Large Language Models locally with an OpenAI-compatible API, so you can swap it in behind existing OpenAI client code without paying per-token or sending data off-server. This guide deploys LocalAI using Docker Compose with Traefik handling automatic HTTPS, persistent model and cache directories, and a working chat-completion test. By the end, you'll have LocalAI serving an OpenAI-compatible API securely at your domain. Set Up the Directory Structure 1. Create the project directories: $ mkdir -p ~/localai/ { models,cache } $ cd ~/localai models/ holds downloaded model files; cache/ persists between restarts. 2. Create the environment file: $ nano .env DOMAIN = localai.example.com LETSENCRYPT_EMAIL = admin@example.com Deploy with Docker Compose 1. Add your user to the Docker group: $ sudo usermod -aG docker $USER $ newgrp docker 2. Create the Compose manifest: $ nano docker-compose.yaml services : traefik : image : traefik:v3.6 container_name : traefik restart : unless-stopped environment : DOCKER_API_VERSION : " 1.44" command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entrypoint.to=websecure" - " --entrypoints.web.http.redirections.entrypoint.scheme=https" - " --certificatesresolvers.le.acme.httpchallenge=true" - " --certificatesresolvers.le.acme.httpchallenge.entrypoint=web" - " --certificatesresolvers.le.acme.email=${LETSENCRYPT_EMAIL}" - " --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json" ports : - " 80:80" - " 443:443" volumes : - /var/run/docker.sock:/var/run/docker.sock:ro - ./letsencrypt:/letsencrypt localai : image : localai/localai:latest-aio-cpu container_name : localai restart : unless-stopped volumes : - ./models:/models:cached - ./cache:/cache:cached healthcheck : test : [ " CMD" , " curl" , " -f" , " http://localhost:8080/readyz" ] interval :

LibreChat is an open-source, ChatGPT-style web UI that supports OpenAI, Anthropic, Azure OpenAI, Gemini, OpenRouter, local OpenAI-compatible endpoints, and more — with MongoDB-backed conversation history and Meilisearch-powered search. This guide deploys LibreChat using its official Compose manifest plus a Traefik override for automatic HTTPS. By the end, you'll have LibreChat running with a registration page and multi-provider chat at your domain over HTTPS. Clone LibreChat and Prepare the Environment 1. Clone the LibreChat repository and check out a stable tag: $ git clone https://github.com/danny-avila/LibreChat.git $ cd LibreChat $ git checkout tags/v0.8.3 2. Find the Meilisearch data directory name pinned by this release: $ grep -o 'meili_data_v[0-9.]*' docker-compose.yml | head -1 3. Create the required data directories (replace meili_data_v1.35.1 if the previous command printed a different name): $ mkdir -p data-node images logs meili_data_v1.35.1 uploads $ sudo chown -R 1000:1000 meili_data_v1.35.1 4. Copy the env template and uncomment the UID/GID lines: $ cp .env.example .env $ nano .env UID = 1000 GID = 1000 Override the Compose Stack with Traefik 1. Create a Compose override that adds Traefik and wires the API to it: $ nano docker-compose.override.yml services : api : labels : - " traefik.enable=true" - " traefik.http.routers.librechat.rule=Host(`librechat.example.com`)" - " traefik.http.routers.librechat.entrypoints=websecure" - " traefik.http.routers.librechat.tls.certresolver=leresolver" - " traefik.http.services.librechat.loadbalancer.server.port=3080" volumes : - ./librechat.yaml:/app/librechat.yaml traefik : image : traefik:v3.6.10 ports : - " 80:80" - " 443:443" volumes : - " /var/run/docker.sock:/var/run/docker.sock:ro" - " ./letsencrypt:/letsencrypt" command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirect

Explore how my day as a senior leader looks now that I use 40 automations to help, and learn more about some of my favorites. The post I automated my job (and it made me a better leader) appeared first on The GitHub Blog .

This post is my submission for DEV Education Track: Build Apps with Google AI Studio . What I Built I set out to build the same app as the one mentioned in the Tutorial. Please create an app that generates a unique new Magic the Gathering card, using Imagen for the visuals, and Gemini to create the text descriptions and stats for the card. Apply the "Sophisticated Dark" design theme to the app. Spammed Fix Errors Non-Stop After this other than the Manual Entry option. Demo My Experience You can't trust Gemini Flash even for the Task provided in the Tutorial Standalone at least and well I spammed Fix Errors and they removed the Auto-Fixing of Errors because of idk an infinite loop or something but well the Error Fixing Experience was quite Meh considering I haven't delved into Vue and React in that level yet so I just 'Vibe Coded' and I found out with this experience that Vibe-Coding is UnCool. I think I would do the other course after properly understanding concepts behind it unlike the way I jumped in this One.

A wide day rather than a deep one — four separate threads across a few projects, each with a lesson worth keeping. I'll teach the patterns and keep the specifics generic. The through-line: make the system honest about what it's actually doing — which queries it fires, whether a service is really up, what a tool will do when you call it twice, and in what order a password change should land. The performance thread got big enough that I split it into its own focused post; here's the short version plus the three other threads. Thread 1 — Stop paying for queries you don't use A sustained sweep through an app (and the package behind it) hunting wasted database work. The highlights: Arm an N+1 detector in dev only. A query detector wired in behind an environment check turns invisible lazy-loads into a visible to-do list. Never in production — it's a developer aid, not a runtime guard. Unused eager loads are N+1s in disguise. Index screens love to with(['creator', 'approver']) for columns a redesign later removed. Not a loop, but the same disease: queries you hydrate and throw away. Delete the eager loads with no consumer in the view. Memoize per-request constants. A default-connection resolver and a sidebar unread count were both recomputed on every call. ??= once, reuse for the rest of the request. Collapse a dashboard's stat queries. ~20 count() calls became one grouped query per table, wrapped in a short-lived cache. A dashboard can tolerate being a few seconds stale; trade live-to-the-second for cheap. The meta-lesson: performance at this layer is mostly removal , and you lock it in with a Pest query-count assertion so nobody quietly re-adds an N+1 six months later. Full write-up in the focused post. Thread 2 — Health checks that actually check Here's a trap I keep seeing in "is it up?" tooling: the check verifies the record exists, or that a config row is present, and calls it green. That's not a health check — that's a config check. The service can be configured per

If you write software for a living and you're considering a trip to China in 2026, the friction you'll hit is not what you expect. The Great Firewall is the headline, but it's rarely what trips up a first-time visitor. What actually breaks your week is the small stuff: a QR code at a noodle shop, a metro turnstile that won't take your foreign card, a hotel Wi-Fi that quietly drops every request to Google. This is a brief survival guide written from a developer's mindset: what's actually changed in 2026, what you can fix before you leave, and what you should just accept. 1. Visa-free entry now covers most Western devs As of late 2025, China extended its 30-day visa-free transit policy to passport holders from 38 countries, including the US, UK, Germany, France, Australia, the Netherlands, and most of the EU. If you're flying in for a vacation, a conference, or even a short remote-work stretch, you may not need to apply for a visa at all — you just need an onward ticket within 30 days. The catch: the rules per nationality drift quarterly, and the official guidance is scattered across embassy pages. I keep a more current breakdown here: FirstTripChina visa-free guide — worth checking the week you book your ticket. 2. The payment problem is the real "API" you need to integrate China runs on two payment rails: Alipay and WeChat Pay. Cash is technically legal but vendors below the level of a 4-star hotel will look at you like you handed them a stone tablet. Foreign credit cards work at airports and big chains; they do not work at the dumpling place you actually want to eat at. The fix that exists in 2026 — and that did not exist three years ago — is "Tour Card" inside Alipay and "International" mode inside WeChat Pay. Both let you link a Visa/Mastercard issued outside China and pay via the same QR system locals use. Setup steps (roughly): Install Alipay (App Store / Play Store, US/EU regions both work). Verify with passport + selfie (KYC takes about 3 minutes). Tap Tour C

Some days the work spreads across a few projects instead of landing as one big feature. Today was that — three distinct threads, each with a lesson worth keeping. I'll keep things generic and teach the pattern rather than the project, but the through-line is the same: move things that were hardcoded or ephemeral into something you can configure, repeat, and trust. Thread 1 — Make scheduled tasks configurable instead of code-only If you've run a Laravel app for any length of time, you know the scheduler lives in code: routes/console.php or the kernel, a wall of ->daily() , ->everyFiveMinutes() , ->cron(...) . That's fine until the day an operator — not a developer — needs to change when something runs. Then you're shipping a deploy just to nudge a cron expression. Silly. Today's work pulled scheduler configuration into a settings-backed UI. The pattern is worth stealing: instead of the schedule being a literal in code, the code reads its cadence from a settings store, and there's an admin screen to edit it. // Instead of a hardcoded cadence... $schedule -> command ( 'subscriptions:reconcile' ) -> daily (); // ...read it from settings, with a sane default baked in. $schedule -> command ( 'subscriptions:reconcile' ) -> cron ( $this -> schedulerSettings -> reconcileCron ?? '0 2 * * *' ); Two things made this clean. First, a SchedulerSettings object (Spatie's settings pattern) so the values are typed, cached, and migratable — not loose rows you Setting::get('...') by string key. Second, grouping the more user-facing schedules behind their own modal rather than dumping every cron in one giant form. A subscription-related schedule belongs next to subscriptions; a platform schedule belongs in admin. Same data, but organized by who needs to touch it . The edge case to watch: a UI-editable cron is a foot-gun if you let people type nonsense. Validate the expression on save, and always keep a default so a blank setting can never silently disable a job. Thread 2 — A load-testing

Lucide has released version 1.0 of its open-source icon toolkit, marking its first stable major release. The update features over 1,600 icons and removes trademarked brand icons due to legal and design concerns. Significant performance improvements have also been made, reducing package size and adding context providers for various frameworks. Users upgrading should be aware of breaking changes. By Daniel Curtis

Sean Klein discusses why "human error" is a dangerous myth in complex systems. Sharing the inside story of Azure’s 2023 global WAN outage, he explains how modern incident analysis looks past the "Five Whys" to uncover systemic issues. Learn how engineering leaders can move away from blame, improve Standard Operating Procedures, and design resilient systems that actively protect their engineers. By Sean Klein

Many cybersecurity professionals have been following Anthropic's announcement about the release of Claude Code Security on Friday. This created the beginning of a panic on the cybersecurity stock market. It also raised a lot of questions from domain experts, investors and security enthusiasts. Anthropic's announcement Anthropic introduces Claude Code Security: a tool that scans full codebases for security vulnerabilities, and can propose fixes directly in developer workflows. The tool leverages the latest foundational model's reasoning capabilities to provide a new experience. In a world where code will be generated only by AI, this can sound very much like code security is dead. Our vision 18 months ago, SAST, SCA, and IaC security were areas where we had real traction and could see ourselves expanding. But as AI tooling started reshaping how code gets written, we made a tough call. We decided to stop these initiatives and go all-in on what we believed would matter most: Protecting enterprises against leaked secrets and mismanaged NHIs . We envisioned a future where identity is crucial for the AI era security, with secrets enabling AIs to access data and take actions . After pioneering in secrets detection for years we witnessed how amplified the problem became as LLM emerged: more API keys for AI services, more code generated, often less secure, more agents requiring sophisticated access to a myriad of tools. All in all, this resulted in more secrets exposed. Yet the problem of overseeing and managing these secrets in a secure way remains unsolved. The paradigm shifted from human hardcoding secrets in their code, to AIs having wide access levels on several systems with humans, coders and non-coders, prompting them and creating new vulnerabilities. 18 months later, let me describe where we stand. What isn't changing Best in class secrets detection GitGuardian is the leader in secrets detection . We are the only solution able to scan large volume of data at scale (5

"What time works for everyone?" is a surprisingly hard question to answer in code. You have to read each person's calendar, line up the busy blocks, respect working hours and time zones, leave buffer time between meetings, and only then find the gaps everyone shares. The Nylas Availability API does all of that in one request: hand it a list of participants and a window, and it returns the time slots that actually work. This post covers finding meeting times from two angles: the HTTP API for your backend, and the nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm checking a calendar. Availability versus Free/Busy There are two endpoints here, and picking the right one saves you work. The Availability endpoint finds bookable slots across a group of participants, applying working hours, buffers, and meeting duration to return times you can actually book. Free/Busy is simpler: it returns the raw busy blocks for one or more email addresses over a window, leaving the slot math to you. Reach for Availability when the question is "when can these people meet?" and you want the answer as a list of open slots. Reach for Free/Busy when you only need to see when calendars are busy, for example to gray out times in a custom UI. Availability is a POST /v3/calendars/availability , an application-level call that takes participants by email, while Free/Busy is grant-scoped at POST /v3/grants/{grant_id}/calendars/free-busy . This post focuses on Availability, since that's the one that answers the scheduling question directly. Find a time across participants The core request lists the participants and the window to search. Each participant is identified by email and must be associated with a valid Nylas grant, since the endpoint reads their calendars. You set start_time and end_time as Unix timestamps for the search window, duration_minutes for how long the meeting is, and interval_minutes for how the candidate start times ar

Writing a clear, well-structured email takes time, and it's the kind of task an LLM is genuinely good at. But wiring up your own prompt-to-email pipeline means picking a model, threading the original message in as context, handling streaming, and keeping it all behind your API keys. The Nylas Smart Compose endpoints do that for you: send a natural-language prompt, get back a written message body, and the reply variant pulls in the original email as context automatically. This post walks through Smart Compose from two angles: the HTTP API for your backend, and the nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm testing a prompt. How Smart Compose works Smart Compose is two endpoints that turn a prompt into a message body. You send a natural-language prompt , and the response comes back with a suggestion field holding the generated text. There's a POST /messages/smart-compose for writing a brand-new message, and a POST /messages/{message_id}/smart-compose for writing a reply, where the original message is folded into the context so the response actually answers it. The key thing to understand is that Smart Compose generates text, it doesn't send anything. The suggestion it returns is a message body you do something with: pass it straight to the Send Message endpoint , or pre-fill it into a draft for a human to review and edit first. That separation is deliberate, since it lets you put a person between the AI's output and the recipient, which is usually what you want for anything an LLM wrote. Two things to know before you start. Smart Compose runs against connected OAuth grants only, not Agent Accounts. The prompt also has a ceiling: up to 1,000 tokens, and a longer prompt returns an error. Generate a new message To write a fresh email, POST /v3/grants/{grant_id}/messages/smart-compose takes a single prompt describing what you want. The response carries the generated body in suggestion , which you then se

Email is how most files still move between people: the signed contract, the PDF invoice, the logo embedded in a newsletter. If your app sends or processes mail, it has to handle attachments, and doing that against each provider means Gmail's attachment encoding, Microsoft Graph's, and raw MIME for IMAP. The Nylas Email API gives you one model for both directions: attach files to outbound messages with the same call you use to send, and pull files off inbound messages with a read-only Attachments API. This post covers both halves from two angles: the HTTP API for your backend, and the nylas CLI for the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm checking a file came through. Two APIs: one to attach, one to read There's a split worth understanding up front. You add attachments through the Messages or Drafts API, as part of sending or saving a message, and you read existing attachments through the dedicated Attachments API. The Attachments API is read-only: it downloads bytes and returns metadata, but it never adds files. That division keeps the model simple, since attaching is part of composing a message and reading is a separate concern. The size of what you're attaching decides how you encode it on the way out. Small files ride inline in the JSON request, larger ones move to a multipart request, and very large files use a separate upload step. On the way in, every attachment, regardless of how it was sent, is fetched the same way: by its attachment_id together with the message_id it belongs to. Get those two ideas straight and the rest is mechanical. Attach a small file inline with Base64 For files that keep the whole request under 3 MB, the simplest path is the application/json schema. You pass each attachment in an attachments array with its content_type , filename , and the file bytes as a Base64-encoded content string. The 3 MB ceiling covers the entire HTTP request, not just the file, so it's the right path for

If you've ever tried to set up Prometheus by following the official getting-started path, you're likely to find a path that does not follow your infrastructure model. Out of the gate, page one mentions kube-prometheus-stack. Page two wants you to install a Helm chart, and page three assumes you already have a cluster running. The documentation for monitoring plain Linux servers is in there somewhere, but you have to dig for it. When you do find it, the tone suggests you are doing something slightly old-fashioned. If that sounds like your setup, the tooling is making this harder than it actually is. Monitoring a fleet of Linux VMs is fairly simple and has been for years. It is just obscured behind documentation that would prefer to sell you something bigger. Modern infrastructure tooling has quietly decided everyone runs Kubernetes. If you don't, the assumption is that you eventually will. Meanwhile, most real-world infrastructure still runs on VMs. TL;DR: Modern observability documentation often assumes you're running Kubernetes. Most small teams aren't. If you're managing a fleet of Linux VMs, node_exporter plus Prometheus gives you everything you need for infrastructure monitoring with a single lightweight agent and a straightforward deployment model. No cluster required. VMs are often the answer For most small businesses, running VMs instead of Kubernetes does not mean you failed to evolve. Most workloads under a certain scale perform better on VMs: One process per box, predictable resource limits, and the ability to ssh in and look at what's happening, which makes it easier to keep track of the infrastructure as a whole. They're cheaper, both financially and in the mental overhead of running them. Backups and snapshots are straightforward in a way stateful Kubernetes still isn't. There's no control plane that itself needs monitoring and upgrades and care. Kubernetes solves problems that mostly pertain to companies with dozens of engineers and hundreds of service

I replaced aaPanel/OpenLiteSpeed with Caddy and shell scripts and turned the process into a benchmark. Two phases (architecture then code), one external code review. The winning model? Not the one you'd expect.

Deploying a Spring Boot backend should be simple in theory. Build the JAR, set the environment variables, connect the database, and ship it. In practice, my deployment exposed several assumptions that worked locally but failed immediately in the cloud. I recently deployed a modular Spring Boot application to Render using Docker, Render Blueprint, PostgreSQL, Redis, Flyway migrations, Spring profiles, Hibernate/JPA, and environment variables. The application worked locally with MySQL and Redis, but deployment exposed several production-specific issues that were easy to miss in local development. This article documents the problems, why they happened, and how I fixed them properly. Who This Article Is For This article is useful if you are deploying a Spring Boot application to Render and your local setup uses MySQL, Redis, Flyway, Docker, or a multi-module Maven structure. It is especially relevant if you are moving from a local MySQL setup to PostgreSQL in the cloud. The Stack The backend was a Java 17 Spring Boot application with multiple Maven modules: alagbafo/ ├── api-contracts ├── core ├── users ├── orders ├── payments ├── wallet ├── notifications ├── admin ├── subscriptions └── app The app module was the actual Spring Boot entry point. Locally, the project used MySQL and Redis: spring.datasource.url = jdbc:mysql://localhost:3306/alagbafo spring.datasource.driver-class-name = com.mysql.cj.jdbc.Driver spring.data.redis.host = localhost spring.data.redis.port = 6379 For Render, the target setup was: Spring Boot app PostgreSQL database Redis-compatible Key Value store Docker deployment Flyway migrations Render Blueprint was the best fit because it allowed the infrastructure to be described in a render.yaml file. Step 1: Dockerfile for a Multi-Module Spring Boot App Because the project was a multi-module Maven application, the Dockerfile had to copy all module pom.xml files before copying the source code. This improves Docker layer caching because dependencies can b

Every World Cup there's a moment. Some player nobody outside their domestic league had heard of scores an absolute screamer in a knockout match, and by the time they've finished celebrating, their follower count is climbing like a rocket. I always found that fascinating, but I could never see it happening in real time. By the time the "X gained 3 million followers!" tweets show up, the surge is already over. So this tournament I built a little tracker that snapshots player follower counts on a schedule and shows me the growth curve as it happens. Here's how it works. Why the official APIs were a dead end My first instinct was to do this "properly" with official APIs. That died fast: Instagram's Graph API won't give you follower counts for accounts you don't own. TikTok's research API is academics-only and takes weeks of applications. X's API now starts at $100/month. I just wanted public follower counts — numbers anyone can see by opening the app. I didn't want a data partnership and a legal review. I ended up using SociaVault , which wraps the public profile data from each platform behind one API and one key. One request, one credit, JSON back. The shared client Everything runs through one tiny helper: // Node 18+ has fetch built in const API_KEY = process . env . SOCIAVAULT_API_KEY ; const BASE = " https://api.sociavault.com " ; async function sv ( path , params ) { const url = new URL ( BASE + path ); Object . entries ( params ). forEach (([ k , v ]) => url . searchParams . set ( k , v )); const res = await fetch ( url , { headers : { " X-API-Key " : API_KEY } }); if ( ! res . ok ) throw new Error ( ` ${ res . status } ${ await res . text ()} ` ); return res . json (); } Grabbing follower counts across platforms Each platform nests the count slightly differently, so I use fallback chains to stay defensive: async function instagramFollowers ( username ) { const data = await sv ( " /v1/scrape/instagram/profile " , { username }); const p = data . data ?. user ?? dat

Web MCP, DevTools per agenti e Modern Web Guidance: meno hype, più strumenti e metodo. Negli annunci recenti di Chrome è emersa una cosa interessante: al netto delle novità “appariscenti”, ciò che resta più utile per il lavoro quotidiano è quello che migliora workflow, diagnosi e decisioni tecniche . Tre filoni, in particolare, disegnano una direzione chiara: Web MCP , DevTools per agenti e Modern Web Guidance . Di seguito una sintesi ragionata di cosa significano, perché contano per il frontend, e come prepararsi a sfruttarli. 1) Web MCP: il ponte tra agenti e Web (senza incollaggi fragili) Se stai lavorando con assistenti/agentic workflow, oggi il collo di bottiglia è quasi sempre lo stesso: far sì che un agente capisca e usi le capacità del browser e delle app web in modo affidabile. Web MCP punta a risolvere questo punto creando un linguaggio/protocollo comune per esporre “capacità” (capabilities) e strumenti (tools) che un agente può invocare in modo strutturato, invece di basarsi su prompt lunghi, scraping o integrazioni ad hoc. Perché è importante per chi fa frontend Automazioni più robuste : meno script fragili che si rompono al primo refactor del DOM. Integrazioni più standard : se più strumenti parlano lo stesso “dialetto”, il costo di collegare agenti e applicazioni scende. Esperienze utente nuove : assistenti che completano task complessi dentro l’app (es. compilazioni, ricerca guidata, operazioni amministrative) con maggiore affidabilità. Implicazione pratica Inizia a ragionare sull’app come su un insieme di azioni esplicite (es. “crea ordine”, “esporta report”, “filtra dataset”), non solo come UI. Questa mentalità ti rende pronto a esporre capacità in modo sicuro e controllato, quando lo stack lo renderà semplice. 2) DevTools per agenti: debugging e performance nell’era dell’automazione Se Web MCP è il “ponte”, DevTools per agenti è la cassetta degli attrezzi per controllare quel ponte: osservabilità, diagnosi e iterazione rapida su flussi in cui non è

The Idea Like a lot of people, I sometimes struggle with time. Not in an "I'm just bad at planning" way — more like my brain genuinely has a hard time feeling how long things take. Twenty minutes can feel like five. I'll think "I have time" right up until I definitely don't. So I built Ready. Ready is a PWA (a web app you can install on your phone like a native app) that counts down to your next event — but not just to the event itself. It counts down to when you need to leave, factoring in both how long it takes you to get ready and how long the journey takes. It sends you push notifications before it's time to move. So you don't accidentally forget about time, run out the door ..late again! The app was designed with time blindness in mind — a challenge many people experience. The tone is always encouraging, never stressful. No red warnings. No "you're late." Just a gentle nudge that has your back. It's also my portfolio project. I'm a junior developer learning in public, and this is me documenting the whole messy, rewarding process. (Which also happens to be great for recalling what you learned) The Stack — and Why I Chose It Before writing a single line of code, I had to decide what to build with. Here's what I landed on and why: Next.js — a framework built on top of React (a popular way to build web interfaces). I chose it because it handles both the frontend (what you see and click) and the backend (the logic running behind the scenes) in one project. Less setup, more building. Supabase — think of it as a database with superpowers. It handles storing your data and user authentication (logging in and out) out of the box. It has a generous free tier, which is great when you're learning. Tailwind CSS — instead of writing traditional CSS in separate files, Tailwind lets you style things directly in your code using short class names like rounded-full or text-teal-600 . Web Push API + Service Workers — A service worker is a small script that runs in the background of

Your site ranks on Google. Your Core Web Vitals are clean. Your meta tags are in order. And yet, when someone asks ChatGPT, Perplexity, or Google's AI Overview a question your business should answer your content doesn't show up. Not because your SEO is broken. Because AI search engines don't work like Google. Google Reads Pages. AI Search Reads Passages. Google crawls your page, indexes it, and ranks it based on signals like backlinks, domain authority, and keyword relevance. The unit of ranking is the page. AI search engines ChatGPT, Perplexity, Claude, Gemini don't rank pages. They retrieve passages. They pull specific chunks of content that directly answer a query, synthesize a response, and surface it to the user often without the user ever clicking through to your site. If your content isn't structured to be retrieved at the passage level, it gets skipped entirely. The page might exist. The answer might be buried somewhere in a 1,500-word article. But if the AI can't extract it cleanly and confidently, it moves on to content that makes its job easier. That's the invisibility problem. And most websites have no idea it's happening to them. The Crawler Problem Nobody Is Talking About Before we even get to content structure, there's a more fundamental issue. AI search engines have their own crawl agents. OpenAI sends GPTBot. Anthropic sends ClaudeBot. Perplexity sends PerplexityBot. These bots need access to your site before any retrieval can happen and a significant number of websites are blocking them without realizing it. This happens in a few ways: Blanket disallow rules in robots.txt. Many sites, especially those built on managed platforms, use wildcard disallow rules that were written for a different era when the only crawler worth worrying about was Googlebot. Those same rules now block AI crawlers by default. Overly aggressive bot protection. Security tools and CDN configurations that flag unusual crawl patterns will sometimes block AI bots before they even