diff --git a/nuxt/content/blog/2026/10/edge-ai-platform.md b/nuxt/content/blog/2026/10/edge-ai-platform.md
new file mode 100644
index 0000000000..ee4bb1ebbf
--- /dev/null
+++ b/nuxt/content/blog/2026/10/edge-ai-platform.md
@@ -0,0 +1,132 @@
+---
+title: "Buyer's Guide: How to Evaluate an Edge AI Platform for Industrial Use"
+metaTitle: "Edge AI Platforms: How to Evaluate and Choose One"
+subtitle: "8 questions to put to every vendor before an edge pilot becomes a production fleet"
+description: "How to evaluate an edge AI platform for industrial use: hardware, integration, offline operation, updates, monitoring, security, and scale."
+date: 2026-10-09
+authors: ["sumit-shinde"]
+image: /blog/2026/10/images/edge-ai-platform.png
+tags:
+  - flowfuse
+  - posts
+tldr:
+  - "Running the model is the easy part. The platform has to support everything around it."
+  - "Check hardware, integration, offline operation, updates, monitoring, security, and scale."
+  - "Test on your real hardware and plan for the full fleet. A single-device pilot hides most production problems."
+meta:
+  faq:
+    - question: "What is an edge AI platform?"
+      answer: "An edge AI platform runs and manages AI applications close to where data is produced, such as on a factory floor. Some platforms only run models. Others also connect to machines and data sources, deploy applications, and manage software across a fleet of devices. The model is often the smaller part of the job; [most of the work is the pipeline around it](/blog/2026/02/edge-ai-is-80-percent-pipeline-and-20-percent-ai/)."
+    - question: "What is the difference between edge AI and cloud AI?"
+      answer: "Edge AI runs models on devices near the machines, so decisions happen locally and keep working without a network connection. Cloud AI sends data to remote servers for processing, which adds latency and depends on a stable connection. Many industrial setups use both: edge for real-time decisions, cloud for training and long-term analysis. Read more in [Edge AI vs Cloud AI in IIoT](/blog/2026/03/edge-ai-vs-cloud-ai-in-iiot/)."
+    - question: "How do you choose an edge AI platform?"
+      answer: "Look beyond whether it runs your model. Check hardware support, integration with your machines and systems, offline operation, remote updates, monitoring, security, and how well it scales. Test each one on your own hardware before you commit. Use the [vendor checklist](#questions-to-ask-before-you-choose) in this guide to compare platforms."
+    - question: "What hardware do I need to run AI at the edge?"
+      answer: "It depends on the model and the workload. Edge AI can run on industrial PCs with GPUs, small embedded computers, or gateways with limited memory. Test your model on the hardware you plan to deploy, alongside everything else that device will run. See how to [run a custom ONNX model on edge devices](/blog/2025/10/custom-onnx-model/)."
+    - question: "What happens to edge AI when the network goes down?"
+      answer: "A well-built edge AI platform keeps running inference locally and [buffers data until the connection returns](/blog/2025/11/store-and-forward-edge-data-buffering/). Check whether anything, such as a license check, needs the cloud to start, and test an outage before you commit."
+cta:
+  type: book-demo
+  title: See FlowFuse run your edge AI application
+  description: Bring your model and your hardware. We'll show you how FlowFuse handles integration, offline operation, updates, and rollback across your fleet.
+---
+
+Most edge AI platforms can run your model. The real test is what happens after the pilot.
+
+<!--more-->
+
+Can it pull data from a PLC, keep working through a network outage, and roll out updates across 50 devices without turning each deployment into a separate project?
+
+We see these challenges across industrial environments. FlowFuse runs in more than 120 plants across 20+ countries, and more than 200 teams use its AI features to build and run applications. The model is only one part of the equation. Data access, connectivity, deployment, and ongoing maintenance are what determine whether a pilot can scale.
+
+::cta-image{src="/blog/2026/10/images/edge-ai-platform-cta.png" alt="Take edge AI from pilot to production with FlowFuse - book a demo" cta="demo"}
+::
+
+This guide covers what to evaluate before choosing an edge AI platform, along with the questions to ask every vendor, including us.
+
+## What Is an Edge AI Platform?
+
+An edge AI platform is the software that runs and manages AI applications close to where data is produced, on industrial PCs, gateways, and other devices on the factory floor. Its purpose is to let AI act on that data locally: taking in signals from [PLCs](/landing/plc/), [cameras](/docs/flowfuse-nodes/edge/rtsp/), and sensors, running the model, and passing the results to the machines, [databases](/docs/node-red/database/), and people that need them, without depending on a round trip to the cloud.
+
+## What to Look For
+
+The list starts with what a single device needs and works outward to running a whole fleet.
+
+### 1. Hardware
+
+Edge hardware varies more than most teams expect. In production, your model might run on an industrial PC with a GPU, a small embedded computer, or a gateway with little memory to spare, and each behaves differently. Benchmarks from a developer's workstation tell you very little about any of them.
+
+Start with the hardware you plan to deploy on, and check which model formats and accelerators the platform supports there. Then test on that hardware, with everything else the device will run. A model that runs comfortably on its own can slow down once it shares the device with data collection, a dashboard, and other applications.
+
+### 2. Integration
+
+A prediction nobody acts on is worth nothing. Data has to reach the model, and its results have to reach the people and systems that respond. This is where many projects get [harder than expected](/blog/2026/02/edge-ai-is-80-percent-pipeline-and-20-percent-ai/).
+
+Say a camera spots a defective part. The result might need to signal a [PLC](/blog/2025/12/what-is-plc/), publish an [MQTT](/blog/2024/06/how-to-use-mqtt-in-node-red/) message, update a record in the [MES](/blog/2025/06/what-is-mes/), and show up on an operator's dashboard. If the platform only runs the model, you build each of those connections with other tools, and every tool is one more thing to maintain, update, and debug.
+
+Look for a platform that keeps the model, the machine connections, and the decision logic in one place. Check that it connects to the systems you actually run, not just a page of partner logos. Keep safety-critical decisions in the PLC; the model's job is to feed it good information.
+
+### 3. Offline Operation
+
+You [run AI at the edge](/blog/2026/03/edge-ai-vs-cloud-ai-in-iiot/) so the line doesn't wait on a remote server for every decision. That only works if the platform keeps working without one.
+
+Ask what happens when the connection drops. Does inference keep running? Does the platform [buffer data and send it later](/blog/2025/11/store-and-forward-edge-data-buffering/), or lose it? Does anything, such as a license check, need the cloud before it can start? How does the system recover when the connection returns?
+
+Demos always have a network. Factory floors don't. Cause an outage on purpose before you commit.
+
+### 4. Updates
+
+The first deployment is rarely the hard part. Change is: a retrained model, a replaced camera, a new feature, a security patch. On one device, you can handle it by hand. On fifty, you can't.
+
+Check how changes [move from development to the floor](/blog/2024/10/how-to-build-automate-devops-pipelines-node-red-deployments/). Can you update devices remotely and in stages? Can you see which version each device runs? Can you [roll back](/blog/2024/09/node-red-version-control-with-snapshots/) a bad update quickly?
+
+### 5. Monitoring
+
+Every deployment has a bad day. A device goes offline, a process crashes, a disk fills up, a camera drifts out of focus. Someone needs to know fast and find the cause without driving to the plant.
+
+The platform should show device status, application state, installed versions, and logs for every site in one place.
+
+Watch the model as well as the device. A model can run without a single error and still get worse as lighting, materials, or products change. Compare its output against real results, so drift shows up on a dashboard instead of in customer returns.
+
+### 6. Security
+
+Pushing updates, reading logs, fixing problems: everything above depends on remote access. That access needs the tightest control.
+
+Check how the platform handles device access, [user permissions](/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/), device communication, credentials, and update delivery. Protect model files too. A model trained on your production data is intellectual property.
+
+Then check that security fits how your team works. If people have to bypass controls to get the job done, they will.
+
+### 7. Scale
+
+Everything above gets harder as the fleet grows. Five devices and five hundred are different jobs. At fleet size, provisioning devices, rolling out updates, and tracking what runs where take up most of the work. If every update needs a site visit, the platform won't last.
+
+Plan for the fleet you expect, even if you start with one device.
+
+## Questions to Ask Before You Choose
+
+Take these into vendor calls and trials. A yes is easy to say, so ask to see it work.
+
+1. Can it run our model on our target hardware, alongside everything else that device runs?
+2. Can it collect data from our machines and send results to our PLCs, MES, and dashboards without extra tools?
+3. If the network drops, does inference keep running, and is any data lost?
+4. Can we update a few devices first, then roll back if something breaks?
+5. Where do we see device health, logs, and model accuracy across every site?
+6. Who can access our devices, and how do you protect credentials and model files?
+7. How many steps does it take to add a new device?
+8. Does it run the whole application, or just the model?
+
+## How FlowFuse Covers All Seven
+
+FlowFuse runs the model and everything around it. Models run as [ONNX](/docs/flowfuse-nodes/ai/onnx/) inside [Node-RED flows](/blog/2025/10/custom-onnx-model/) on the gateways and industrial PCs already on your floor, whether they predict bearing failures from vibration data or inspect parts through an [RTSP camera](/docs/flowfuse-nodes/edge/rtsp/). The same flow talks to PLCs over MQTT and [OPC UA](/blog/2025/07/reading-and-writing-plc-data-using-opc-ua/), writes to your databases, and keeps running offline, [buffering data](/blog/2025/11/store-and-forward-edge-data-buffering/) until the connection returns.
+
+From one place, you roll that flow out to one device or a hundred, see which version each one runs, check logs remotely, and [roll back](/blog/2024/09/node-red-version-control-with-snapshots/) a bad update. [Role-based access](/blog/2024/04/role-based-access-control-rbac-for-node-red-with-flowfuse/) controls who can change what.
+
+AI also helps you build and run these applications. [LLM nodes](/docs/flowfuse-nodes/ai/llm-nodes/) bring OpenAI, Anthropic, Gemini, or a local Ollama model into any flow. [FlowFuse Expert](/blog/2026/05/flowfuse-expert-building-flows/), the assistant in the editor, turns a plain description into flows and dashboards, explains flows you inherited, and answers questions about live machine state. By default, nothing it builds goes live until you deploy it.
+
+If your company already uses Microsoft Copilot, ChatGPT, or Claude, you can [connect it to FlowFuse](/blog/2026/09/industrial-ai-agent/) instead, limited to the teams and access level you choose. You can also [build your own MCP servers](/blog/2025/10/building-mcp-server-using-flowfuse/) so agents can query your plant data. Either way, AI follows the same role-based access as your team, can't delete anything, and FlowFuse logs every action.
+
+## Final Thoughts
+
+A demo proves the model runs. It doesn't prove the platform will hold up when you need to update a model on fifty devices, recover from a network outage, or work out why one line's results have slipped.
+
+So test for those situations before you choose. Disconnect the network and see what still works. Push an update, then roll it back. Add more devices and see how much setup each one needs. It takes a day or two, and it tells you more than any feature list.
diff --git a/nuxt/public/blog/2026/10/images/edge-ai-platform-cta.png b/nuxt/public/blog/2026/10/images/edge-ai-platform-cta.png
new file mode 100644
index 0000000000..15ee1ce6c4
Binary files /dev/null and b/nuxt/public/blog/2026/10/images/edge-ai-platform-cta.png differ
diff --git a/nuxt/public/blog/2026/10/images/edge-ai-platform.png b/nuxt/public/blog/2026/10/images/edge-ai-platform.png
new file mode 100644
index 0000000000..2504242dae
Binary files /dev/null and b/nuxt/public/blog/2026/10/images/edge-ai-platform.png differ