Forem: DigitalOcean

Build an End-to-End RAG Pipeline for LLM Applications

DigitalOcean — Wed, 01 Apr 2026 01:06:34 +0000

This article was originally written by Shaoni Mukherjee (Technical Writer)

Large language models have transformed the way we build intelligent applications. Generative AI Models can summarize documents, generate code, and answer complex questions. However, they still face a major limitation: they cannot access private or continuously changing knowledge unless that information is incorporated into their training data.

Retrieval-Augmented Generation (RAG) addresses this limitation by combining information retrieval systems with generative AI models. Instead of relying entirely on the knowledge embedded in model weights, a RAG system retrieves relevant information from external sources and provides it to the language model during inference. The model then generates a response grounded in this retrieved context.

An end-to-end RAG pipeline refers to the full system that manages this process from beginning to end. It includes ingesting documents, transforming them into embeddings, storing them in a vector database, retrieving relevant information for a user query, and generating an answer using a large language model.

This architecture is increasingly used in modern AI systems such as enterprise knowledge assistants, internal documentation search engines, developer copilots, and AI customer support tools. Organizations adopt RAG because it allows models to remain lightweight while still accessing large knowledge bases that change frequently.

In this tutorial, we will walk through how to design and build a complete RAG pipeline. Along the way, we will explore architectural considerations, optimization strategies, and production challenges developers encounter when deploying retrieval-based AI systems.

Key Takeaways

RAG combines retrieval and generation for more accurate AI systems: Retrieval-Augmented Generation (RAG) bridges the gap between static language models and dynamic, real-world data. Instead of relying only on pre-trained knowledge, it fetches relevant information at runtime and uses it to generate answers. This makes responses more accurate, up-to-date, and context-aware. It is especially useful for applications like chatbots, internal knowledge assistants, and search systems. Overall, RAG helps reduce hallucinations and improves trust in AI-generated outputs.
Vector embeddings are the foundation of semantic search in RAG: Embeddings convert text into numerical vectors that capture meaning rather than exact wording. This allows the system to understand similarity between queries and documents even if they use different phrasing. As a result, retrieval becomes more intelligent and context-driven instead of keyword-based. High-quality embedding models like text-embedding-3-large or bge-large-en can significantly improve retrieval performance. Choosing the right embedding model directly impacts the overall quality of your RAG system.
Each component of the pipeline plays a critical role: A RAG system is made up of multiple steps, including ingestion, chunking, embedding, storage, retrieval, and generation. If any one component is poorly optimized, it can affect the entire pipeline’s performance. For example, bad chunking can lead to irrelevant retrieval, even if your embedding model is strong. Similarly, weak retrieval will result in poor answers, no matter how powerful the language model is. This is why building an end-to-end RAG system requires careful design and tuning at every stage.
Evaluation is essential for building reliable RAG applications: It is not enough to just build a RAG pipeline, but you must also evaluate how well it performs. This includes checking whether the system retrieves the correct documents and whether the generated answers are accurate and grounded. Metrics like precision and recall help measure retrieval quality, while human evaluation helps assess answer correctness. Creating benchmark datasets with known questions and answers makes it easier to track improvements over time. Continuous evaluation ensures your system remains reliable in production.

Understanding the RAG System Architecture

Before implementing the pipeline, it is important to understand how the different components interact. A typical RAG system architecture can be divided into two major workflows: the indexing pipeline and the retrieval pipeline.

The indexing pipeline prepares the knowledge base so that it can be searched efficiently. During this stage, documents are ingested, cleaned, split into chunks, converted into embeddings, and stored in a vector database. This process is usually executed offline or periodically when new data becomes available.

The retrieval pipeline operates during inference. When a user asks a question, the system converts that query into an embedding, searches the vector database for semantically similar chunks, and provides those retrieved passages to the language model. The model then generates a response using both the query and the contextual information.

A simplified representation of the pipeline looks like this:

Document Sources
       (PDFs, Docs, APIs, Knowledge Base)
                        |
                        v
               Document Processing
                        |
                        v
                  Text Chunking
                        |
                        v
               Embedding Generation
                        |
                        v
               Vector Database Index
                        |
                        v
User Query → Query Embedding → Similarity Search
                        |
                        v
             Retrieved Context Chunks
                        |
                        v
                  LLM Generation
                        |
                        v
                  Final Response

This architecture enables the system to retrieve information dynamically rather than relying solely on model training.

Data Ingestion in a RAG Pipeline

The first stage of the pipeline involves gathering the data that the AI system will use as its knowledge source. In many real-world applications, this information is distributed across multiple systems. Organizations may store documentation in internal knowledge bases, PDFs, wikis, product manuals, or database records.

The ingestion stage extracts textual information from these sources and prepares it for processing. Depending on the data format, ingestion may involve parsing HTML pages, converting PDFs to text, or querying APIs to retrieve structured records.

At this stage, developers often implement preprocessing steps such as removing redundant formatting, normalizing whitespace, and filtering irrelevant sections. These steps are important because retrieval performance strongly depends on the quality of the text data stored in the system.

For enterprise knowledge retrieval systems, ingestion pipelines are usually automated and scheduled. For example, an internal documentation chatbot might update its knowledge base daily by ingesting the latest documentation changes from a repository.

Text Chunking: Preparing Documents for Retrieval

After ingestion, documents must be divided into smaller pieces before they can be embedded. This step, known as text chunking, plays a critical role in the overall performance of the RAG pipeline.

Large documents cannot be embedded effectively because embedding models have token limits and because large chunks reduce retrieval precision. Instead, documents are broken into manageable segments that capture a coherent piece of information.

Chunk size is typically chosen between 200 and 500 tokens. Smaller chunks provide more precise retrieval results, while larger chunks preserve more contextual information. Many production pipelines use overlapping chunks to prevent important sentences from being split across boundaries.

The following diagram illustrates how a long document is transformed into multiple overlapping chunks:

Original Document
-------------------------------------------------------
| Paragraph 1 | Paragraph 2 | Paragraph 3 | Paragraph 4 |
-------------------------------------------------------

After Chunking
-------------------------------------------------------
| Chunk 1 | Chunk 2 | Chunk 3 | Chunk 4 | Chunk 5 |
-------------------------------------------------------

Chunk Example
Chunk 1: Paragraph 1 + part of Paragraph 2
Chunk 2: Paragraph 2 + part of Paragraph 3

Choosing an effective chunking strategy significantly improves retrieval accuracy because each chunk represents a focused semantic concept.

Embedding Generation

Once documents are divided into chunks, each chunk must be converted into a numerical representation called an embedding. Embeddings transform text into high-dimensional vectors that capture semantic meaning.

For example, two sentences that express similar ideas will produce vectors that are close to each other in vector space. This property allows vector databases to retrieve semantically related text even when the wording differs.

Embedding models are trained using large datasets and transformer architectures. When a chunk is processed, the model generates a vector with hundreds or thousands of dimensions. These vectors serve as the foundation for similarity search.

Embedding generation occurs during both indexing and retrieval. During indexing, embeddings are generated for each document chunk. During retrieval, the user’s query is also converted into an embedding so that it can be compared against stored vectors.

This mechanism allows the RAG system to perform semantic search, which is far more powerful than traditional keyword matching.

Vector Embedding

Vector embeddings are dense numerical representations of data, which can be text, images, or audio. Vector embeddings are used to capture the semantic meaning of the data in a high-dimensional vector space. In an end-to-end RAG pipeline, embeddings are used to convert both documents and user queries into vectors so that similarity between them can be measured using metrics like cosine similarity. This allows the system to retrieve context based on meaning rather than exact keyword matches, making responses more accurate and relevant.

For example, even if a query doesn’t contain the same words as a document, embeddings can still identify it as relevant if the underlying intent is similar. Popular embedding models used in RAG systems include text-embedding-3-large, all-MiniLM-L6-v2, bge-large-en, and e5-large-v2, each offering different trade-offs in performance, cost, and deployment flexibility.

Storing Vectors in a Database

After embeddings are created, they must be stored in a specialized database capable of performing fast similarity searches. These systems are known as vector databases and form the core of the RAG retrieval infrastructure.

Unlike traditional databases that index numeric or textual fields, vector databases are optimized to search across high-dimensional vectors. They use approximate nearest neighbor algorithms to identify vectors that are closest to a query embedding.

The structure of a stored vector typically includes the embedding itself, the original text chunk, and metadata describing the source of the information. Metadata can include document identifiers, timestamps, or categories that allow filtering during retrieval.

A simplified representation of vector storage looks like this:

Vector Database

ID     Vector Embedding        Text Chunk
---------------------------------------------------------
1   [0.12, -0.44, 0.92...]   "RAG combines retrieval..."
2   [0.55, 0.33, -0.14...]   "Vector databases enable..."
3   [-0.77, 0.08, 0.62...]   "Embeddings represent..."

Popular vector database technologies include managed services and open-source platforms designed specifically for AI workloads. The choice often depends on scale, infrastructure preferences, and latency requirements.

Retrieval in a RAG Pipeline

When a user submits a question, the system begins the retrieval stage. The query is first converted into an embedding using the same embedding model used during indexing. Maintaining the same embedding model is important because similarity comparisons rely on consistent vector representations.

The query embedding is then sent to the vector database. The database performs a similarity search to find document chunks whose embeddings are closest to the query vector. These chunks represent the pieces of information most relevant to the user’s question.

The retrieved chunks are then combined and passed to the language model as contextual input. The model uses this context to generate a response grounded in actual documents rather than relying solely on its training data.

This process ensures that answers are based on real knowledge sources and can be updated whenever the underlying documents change.

Generation with a Large Language Model

The final stage of the pipeline involves generating a response using a language model. At this point, the system already has two pieces of information: the user’s question and the retrieved context.

These elements are combined into a prompt that instructs the model to answer the question using the provided information. Because the context is derived from authoritative documents, the model’s output becomes significantly more reliable and factual.

This stage also allows developers to control how responses are generated. Prompts may instruct the model to summarize information, provide citations, or answer in a specific format. Some systems also include guardrails that prevent hallucinations or restrict responses to retrieved information.

For example, if a user asks a question, the system first pulls the most relevant text from your knowledge base, then the LLM rewrites that content into a helpful answer, making it more conversational, structured, and easy to understand. This step is what makes RAG powerful, because it combines accurate, up-to-date information with fluent natural language generation, reducing hallucinations and improving answer quality.

Code Demo: Building a Simple End-to-End RAG Pipeline

The following example demonstrates how a basic RAG pipeline for LLM applications can be implemented in Python. The example uses document loading, chunking, embeddings, and a vector database to create a minimal working pipeline.

Install dependencies

pip install langchain chromadb sentence-transformers openai

Load documents

from langchain.document_loaders import TextLoader

loader = TextLoader("knowledge_base.txt")
documents = loader.load()

Split documents into chunks

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
   chunk_size=500,
   chunk_overlap=100
)

chunks = splitter.split_documents(documents)

Generate embeddings

from langchain.embeddings import HuggingFaceEmbeddings

embeddings = HuggingFaceEmbeddings(
   model_name="sentence-transformers/all-MiniLM-L6-v2"
)

Store vectors

from langchain.vectorstores import Chroma

vector_db = Chroma.from_documents(
   documents=chunks,
   embedding=embeddings
)

Retrieval and generation

from langchain.chains import RetrievalQA
from langchain.chat_models import ChatOpenAI

llm = ChatOpenAI()

qa_chain = RetrievalQA.from_chain_type(
   llm=llm,
   retriever=vector_db.as_retriever()
)

response = qa_chain.run(
   "What is retrieval augmented generation?"
)

print(response)

This simple implementation demonstrates how document retrieval and language models can be combined into a working RAG system.

Evaluating RAG System Performance

Evaluating a RAG system is important because you need to be sure that it is not only retrieving the right information but also generating correct and useful answers from it. In simple terms, a good RAG pipeline should find the right content and then explain it correctly.

First, let’s look at retrieval evaluation. This checks whether the system is pulling the right documents from your database. Imagine you have a knowledge base about cloud services, and a user asks, “How can I run AI models on GPUs?”. If your system retrieves documents about GPU Droplets or AI infrastructure, that’s a good sign. But if it returns unrelated content like pricing pages or networking docs, retrieval quality is poor. Metrics like recall (did we find all relevant documents?) and precision (were the retrieved documents actually relevant?) help measure this. For example, if 5 documents are relevant but your system only retrieves 2, recall is low.

Next is generation evaluation, which focuses on the answer produced by the language model. Even if retrieval is correct, the model (like GPT-4 or Llama 3) might still generate incomplete or incorrect responses. For instance, if the retrieved document clearly says “GPU droplets support CUDA workloads”, but the model responds with “GPU support is limited”, that’s a problem. This is why human evaluation is often needed to check if the answer is factually correct, complete, and grounded in the provided context. Automated metrics struggle to detect things like s or subtle inaccuracies.

To make evaluation consistent, teams usually create an evaluation dataset. This is a collection of sample questions along with their correct answers and sometimes the expected source documents. For example:

Question: “What are GPU droplets used for?”
Expected answer: “They are used for AI/ML workloads, training models, and high-performance computing.”

You can then run your RAG system on this dataset and compare its answers against the expected ones. Over time, this helps you track improvements, catch errors, and tune your system (for example, by improving chunking, choosing a better embedding model, or adjusting prompts).

In practice, strong RAG evaluation combines:

Retrieval checks: Did we fetch the right information?
Answer checks: Did we explain it correctly?
Continuous testing: Are we improving over time?

This ensures your RAG pipeline is reliable, accurate, and ready for real-world use.

Scaling and Production Considerations

Prototype RAG pipelines often work well with small datasets, but production deployments introduce additional challenges. Large organizations may store millions of document chunks, requiring scalable infrastructure for indexing and retrieval.

Latency also becomes an important concern. Vector searches, embedding generation, and LLM inference all contribute to response time. Developers must carefully optimize these components to ensure interactive performance.

Production systems frequently incorporate caching layers, query batching, and efficient indexing strategies. Monitoring tools are also used to track retrieval accuracy, system latency, and cost per query.

Cost and Latency Optimization

Operating a RAG pipeline at scale can become expensive if not carefully optimized. Each query may require embedding generation, vector search, and language model inference.

Several strategies help reduce these costs. Caching responses for frequently asked questions prevents repeated model inference. Limiting the number of retrieved chunks also reduces token usage and speeds up generation.

Another important technique is re-ranking. Instead of sending many retrieved documents to the language model, a re-ranking model selects the most relevant passages before generation. This improves response quality while reducing computational overhead.

RAG vs Fine-Tuning

A common question among developers is whether to use retrieval-augmented generation or fine-tuning.

Fine-tuning changes a model’s internal weights by training it on additional datasets. This approach works well for teaching models specific styles or behaviors. However, it is less effective for continuously changing knowledge because retraining the model is expensive and time-consuming.

RAG systems take a different approach by keeping the model unchanged while retrieving knowledge dynamically. This makes them ideal for applications where information changes frequently, such as product documentation or customer support knowledge bases.

For most knowledge-intensive applications, RAG provides a more flexible and maintainable solution.

Conclusion

Building an end-to-end RAG pipeline is about combining the strengths of retrieval systems and large language models to create applications that are both accurate and context-aware. Instead of relying only on pre-trained knowledge, a RAG system can fetch relevant information in real time and use models like GPT-4 or Llama 3 to generate clear, human-like responses grounded in that data. In this article, we understood each of the steps used to create the RAG pipeline from data ingestion and chunking to vector embeddings, retrieval, and response generation. Each component plays a critical role, and even small improvements (like better chunking strategies or choosing the right embedding model) can significantly impact overall performance. As organizations continue to build AI-powered applications, RAG stands out as a practical and scalable approach for use cases like chatbots, knowledge assistants, and document search. By continuously evaluating and refining your pipeline, you can create systems that are not only intelligent but also reliable and production-ready.

Resources

Tutorial: Deploy NVIDIA's NemoClaw in One Click

DigitalOcean — Mon, 23 Mar 2026 18:28:14 +0000

This article was originally written by Amit Jotwani (Staff Developer Advocate at DigitalOcean)

Key Takeaways

NemoClaw is an open-source stack from NVIDIA designed to help developers run OpenClaw securely.
DigitalOcean offers NemoClaw 1-Click Droplets that enable you to set up this stack on a CPU-optimized virtual machine and run NemoClaw.
This tutorial illustrates how to SSH into your Droplet, configure inference settings and policies, connect to NemoClaw, and effectively reconnect after the initial setup.

At GTC 2026, NVIDIA announced NemoClaw, an open-source stack that makes it easy to run OpenClaw autonomous agents securely. OpenClaw is an open-source agent platform that Jensen Huang called “the operating system for personal AI.” We covered how to run OpenClaw on a Droplet in an earlier tutorial. NemoClaw takes a different approach — it wraps OpenClaw with sandboxing, security policies, and inference routing through NVIDIA’s cloud.

NemoClaw is still in alpha, so expect rough edges. Interfaces may change, features might be incomplete, and things could break. But if you’re curious to try it out or just want to see what NVIDIA’s vision for agents looks like, this tutorial will get you up and running on a DigitalOcean Droplet in under 10 minutes.

Prerequisites

Before you begin, you’ll need:

A DigitalOcean account (sign up here if you don’t have one)
An NVIDIA account to generate an API key at build.nvidia.com

Step 1 - Create a Droplet from the Marketplace

Head to the NemoClaw 1-Click Droplet on the DigitalOcean Marketplace. Click Create NemoClaw Droplet.

When configuring the Droplet, select the CPU-Optimized plan with Premium Intel. You’ll want the option with 32 GB of RAM and 16 CPUs. NemoClaw runs Docker containers, a Kubernetes cluster (k3s), and the OpenShell gateway, so it needs the headroom.

Pick a data center region near you, add your SSH key, and hit Create Droplet.

Heads up: This Droplet costs $336/mo, so make sure to destroy it when you’re done experimenting. It adds up fast if you forget about it.

Step 2 - SSH into the Droplet

Once your Droplet is ready, SSH in:

ssh root@your_server_ip

You’ll see the usual Ubuntu login banner, and then the NemoClaw onboarding wizard will kick off automatically. It runs through a series of preflight checks, making sure Docker is running, installing the OpenShell CLI, and spinning up the gateway. You’ll see checkmarks fly by as each step completes.

Step 3 - Walk Through the Onboard Wizard

The onboarding wizard will ask you a few things. Here’s what to do at each prompt:

Sandbox Name

The first prompt asks for a sandbox name. Just press Enter to accept the default (my-assistant). The wizard will then create the sandbox, build the container image, and push it to the gateway. This takes a couple of minutes, and you’ll see it run through about 20 steps as it builds and uploads everything.

NVIDIA API Key

Once the sandbox is ready, the wizard asks for your NVIDIA API key. In this setup, inference is routed through NVIDIA’s cloud using the nvidia/nemotron-3-super-120b-a12b model, so it needs a key to authenticate.

To get your key, head to build.nvidia.com/settings/api-keys, sign in, and click Generate API Key. Give it a name, pick an expiration, and hit Generate Key.

Copy the key (it starts with nvapi-), paste it into the terminal prompt, and press Enter.

The wizard saves the key to ~/.nemoclaw/credentials.json and sets up the inference provider. You’ll see it confirm the model and create an inference route.

Policy Presets

After the inference setup, NemoClaw sets up OpenClaw inside the sandbox and then asks about policy presets. You’ll see a list of available presets including Discord, Docker Hub, Hugging Face, Jira, npm, PyPI, Slack, and more. These control what external services the agent is allowed to reach.

At the bottom, the wizard asks:

Apply suggested presets (pypi, npm)? [Y/n/list]:

Type n and press Enter. These presets grant the sandbox network access to package registries, which you don’t need for a basic setup. You can always add them later if your agent needs to install packages.

Once onboarding finishes, you’ll see a clean summary with your sandbox details and the commands you’ll need going forward:

Sandbox    my-assistant (Landlock + seccomp + netns)
Model      nvidia/nemotron-3-super-120b-a12b (NVIDIA Cloud API)
NIM        not running

Run:       nemoclaw my-assistant connect
Status:    nemoclaw my-assistant status
Logs:      nemoclaw my-assistant logs --follow

Step 4 - Connect to NemoClaw

Now for the fun part. Connect to your sandbox.

nemoclaw my-assistant connect

This drops you into a shell inside the sandboxed environment. From here, launch the OpenClaw TUI (terminal user interface):

openclaw tui

That’s it. You should see the OpenClaw chat interface come up. The agent will greet you and introduce itself, ready to chat.

Type a message and hit Enter. You’re now talking to an AI agent running inside a secure, sandboxed environment on your own Droplet.

Reconnecting After a New SSH Session

If you close your terminal and SSH back into the Droplet later, you’ll find that nemoclaw and related commands aren’t available. That’s because the onboarding script installed everything through nvm in a separate shell, and that doesn’t carry over to new sessions.

Run this once to fix it permanently. It adds nvm to your .bashrc so it loads automatically on every login:

echo 'export NVM_DIR="$HOME/.nvm"' >> ~/.bashrc && echo '[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"' >> ~/.bashrc && echo '[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"' >> ~/.bashrc && source ~/.bashrc

Then reconnect to your sandbox and launch the TUI the same way as before:

nemoclaw my-assistant connect

openclaw tui

Everything picks up right where you left off. Your sandbox and agent are still running.

What's Next

By default, the sandbox has limited network access, so the agent can’t reach external services out of the box. To unlock more capabilities - like connecting to Slack, GitHub, or pulling packages from PyPI - you’ll want to configure policy presets. Check the NemoClaw documentation for the full list of available integrations and how to set them up.

NemoClaw is still very early, so expect things to be rough around the edges. But if you want to get a feel for where always-on agents are headed, this is a good way to start poking around.

Resources

GPT 5.3 Codex is the Next Level for Agentic Coding

DigitalOcean — Thu, 19 Mar 2026 20:00:00 +0000

Agentic Coding models are one of the obvious and most impressive applications of LLM technologies, and their development has gone hand in hand with massive impacts to markets and job growth. There are numerous players vying to create the best new LLM for all sorts of applications, and many would argue no company and their products in this space have more of a significant impact than OpenAI.

GPT‑5.3‑Codex is a truly impressive installment in this quest to create the best model. OpenAI promises that GPT-5.3-Codex is their most capable Codex model yet, advancing both coding performance and professional reasoning beyond GPT-5.2-Codex. Benchmark results show state-of-the-art performance on coding and agentic benchmarks like SWE-Bench Pro and Terminal-Bench, reflecting stronger multi-language and real-world task ability. Furthermore, the model is ~25% faster than GPT-5.2-Codex for Codex users thanks to infrastructure and inference improvements. Overall, GPT‑5.3‑Codex might be the most powerful agentic coding model ever released (Source).

So let’s see what it can do. Now available on the DigitalOcean GradientTM AI Platform and all OpenAI ChatGPT and Codex resources, we can test the model to see how it performs. In this tutorial, we will show how to use Codex to write a completely new project from scratch. We are going to make a Z-Image-Turbo Real-Time image-to-image application using GPT‑5.3‑Codex, without any user coding! Follow along to learn what GPT‑5.3‑Codex has to offer, how to use GPT‑5.3‑Codex for yourself, and a guide to vibe coding new web applications from scratch!

Key Takeaways

State-of-the-Art Agentic Performance: GPT-5.3-Codex delivers impressive results across software engineering and agentic tasks, outperforming GPT-5.2-Codex in reasoning, multi-language capability, and real-world coding evaluations like SWE-Bench Pro and Terminal-Bench 2.0.
Getting Started with GPT-5.3-Codex on GradientTM AI Platform is easy: All you need is access to the DigitalOcean Platform to begin integrating your LLM’s calls seamlessly into your workflows at scale.
From Prototype to Production in Record Time: With roughly 25% improved speed and real-time interactive steering, GPT-5.3-Codex feels less like a static generator and more like a responsive engineering partner capable of iterating, debugging, and refining projects alongside you. By handling scaffolding, architecture decisions, edge cases, and deployment-ready details, GPT-5.3-Codex can dramatically compress development timelines, making it possible to ship fully functional applications from scratch more quickly than ever (Source).

GPT‑5.3‑Codex Overview

GPT-5.3-Codex is a major agentic coding model upgrade that combines stronger reasoning and professional knowledge with enhanced coding performance, runs about 25 % faster than GPT-5.2-Codex, and excels on real-world and multi-language benchmarks like SWE-Bench Pro and Terminal-Bench. It’s designed to go beyond simple code generation to support full software lifecycle tasks (e.g., debugging, deployment, documentation) and lets you interact and steer it in real time while it’s working, making it feel more like a collaborative partner than a generator. It also has expanded capabilities for long-running work and improved responsiveness, with broader availability across IDEs, CLI, and apps for paid plans. (Source)

As we can see from the table above, GPT‑5.3‑Codex is a major step forward over GPT‑5.2‑Codex across software engineering, agentic, and computer use benchmarks. This, paired with the marked improvement in efficiency, make for an incredible indicator of how great this model is. We think this is a significant upgrade to previous GPT Codex model users, as well as new users looking for a powerful agentic coding tool to aid their process.

Getting Started with GPT-5.3-Codex

There are two ways to get started with GPT-5.3-Codex that we recommend to developers. First, is accessing the model with Serverless Inference through the GradientTM AI Platform. With Serverless Inference, we can Pythonically integrate the LLM generations into any pipeline. All you need to do is create a model access key, and begin generating! For more information on getting started, check out the official documentation.

The other way to get started quickly is the official OpenAI Codex application. It’s easy to get started with Codex on your local machine. Simply download the application onto your computer, and launch it. You will then be prompted to log in to your account. From there, simply choose which project you wish to work in, and you’re ready to get started!

Vibe Coding a Z-Image-Turbo Web Application with GPT‑5.3‑Codex

So now that we have heard about how GPT‑5.3‑Codex performs, let’s see it in action. For this experiment, we sought to see how the model performed on a relatively novel assignment that has a basis in past applications. In this case, we asked it to create a real-time image-to-image pipeline for Z-Image-Turbo that uses webcam footage as image input.

To do this, we created a blank new directory/project space to work in. We then asked the model to create a skeleton of the project to begin, and then iteratively added in the missing features on subsequent queries. Overall, we were able to create a full working version of the application with just 5 prompts and 30 minutes of testing. This extreme speed made it possible to ship the project in less than a day, from inspiration to completion. Now let’s take a closer look at the application project itself.

This project, which can be found here, is a real-time webcam-driven image-to-image generation application built in Python around a Gradio interface and a dedicated Z-Image-Turbo inference engine, where the UI in app.py presents side-by-side live input and generated output panes, parameter controls, and explicit Start/Stop gating so inference only runs when requested, while the backend in inference.py loads Tongyi-MAI/Z-Image-Turbo via ZImageImg2ImgPipeline, introspects the pipeline signature to bind the correct image-conditioning argument, enforces true img2img semantics instead of prompt-only generation, and executes inference in torch.inference_mode() with dynamic argument wiring so behavior adapts to the installed diffusers API. Critically, it can compute per-frame target resolution from webcam aspect ratio, snapping dimensions to a model-friendly multiple (default 16), and caps both sides below 1024, then applies post-generation safeguards that made the app stable in practice: dtype strategy (auto preferring bf16 then fp32, avoiding fp16 black-frame failure modes), degenerate-output detection with automatic float32 recovery, robust PIL/NumPy/Tensor output decoding and normalization, effective-strength clamping to preserve source structure, frame-hash seed mixing so scene changes influence results, and configurable structure-preserving input blending, all parameterized in config.py and documented in the README.md, with runtime status reporting latency plus internal diagnostics (pipe, dtype, size, effective strength, blend, seed, warnings) so you can observe exactly how each frame is being processed.

Closing Thoughts

GPT-5.3-Codex feels less like an incremental update and more like a meaningful shift in how developers interact with code. The combination of stronger reasoning, benchmark gains seen in testing, and a noticeable speed improvement makes it clear that agentic coding is maturing into something even more production-ready. What once required hours of boilerplate, debugging, and manual wiring can now be orchestrated through iterative prompts and high-level direction. As we demonstrated with the Z-Image-Turbo real-time application, a fully functional project can move from blank directory to working prototype in much less time traditionally required. While the actual results and performance benefits you experience will vary based on specific project requirements, complexity, and individual developer workflows, we are confident that GPT-5.3-Codex provides a substantial upgrade and a meaningful step forward in agentic coding capability, as evidenced by its stronger reasoning and measurable benchmark gains.

We recommend trying out GPT-5.3-Codex in all contexts, especially with DigitalOcean’s GradientTM AI Platform!

Getting Started with Qwen3.5 Vision-Language Models

DigitalOcean — Tue, 17 Mar 2026 16:00:00 +0000

This article was originally written by James Skelton (Senior AI/ML Technical Content Strategist II)

Vision Language models are one of the most powerful and highest potential applications of deep learning technologies. The reasoning behind such a strong assertion lies in the versatility of VL modeling: from document understanding to object tracking to image captioning, vision language models are likely going to be the building blocks of the incipient, physical AI future. This is because everything that we can interact with that will be powered by AI - from robots to driverless vehicles to medical assistants - will likely have a VL model in its pipeline.

This is why the power of open-source development is so important to all of these disciplines and applications of AI, and why we are so excited about the release of Qwen3.5 from Qwen Team. This suite of completely open source VL models, ranging in size from .8B to 397B (with activated 17B) parameters, is the clear next step forward for VL modeling. They excel at bench marks for everything from agentic coding to computer use to document understanding, and nearly match closed source rivals in terms of capabilities.

In this tutorial, we will examine and show how to make the best use of Qwen3.5 using a Gradienttm GPU Droplet. Follow along for explicit instructions on how to setup and run your GPU Droplet to power Qwen3.5 to power applications like Claude Code and Codex using your own resources.

Key Takeaways

Qwen3.5 VL demonstrates the growing power of open multimodal AI. The fully open-source model suite spans from 0.8B to 397B parameters and achieves strong benchmark performance across tasks like coding, document understanding, and computer interaction, approaching the capabilities of leading proprietary models.
Its architecture enables efficient large-scale multimodal training. By decoupling vision and language parallelism strategies, using sparse activations, and employing an FP8 training pipeline, Qwen3.5 improves hardware utilization, reduces memory usage, and maintains high throughput even when training on mixed text, image, and video data.
Developers can deploy Qwen3.5 on their own infrastructure. With tools like Ollama and GPU Droplets, it is possible to run large Qwen3.5 models locally or in the cloud to power applications such as coding assistants, computer-use agents, and custom AI tools without relying on proprietary APIs.

Qwen3.5: Overview

Qwen3.5 is a fascinating model suite with a unique architecture. It “enables efficient native multimodal training via a heterogeneous infrastructure that decouples parallelism strategies across vision and language components” (Source). This helps to make it avoid uniform approaches’ inefficiencies, such as over-allocating compute to lighter modalities, synchronization bottlenecks between vision and language towers, memory imbalance across devices, and reduced scaling efficiency when both modalities are forced into the same parallelism strategy.

By leveraging sparse activations to enable overlapping computation across model components, the system reaches nearly the same training throughput as pure text-only baselines even when trained on mixed text, image, and video datasets. Alongside this, a native FP8 training pipeline applies low-precision computation to activations, Mixture-of-Experts (MoE) routing, and GEMM operations. Runtime monitoring dynamically preserves BF16 precision in numerically sensitive layers, reducing activation memory usage by roughly 50% and delivering more than a 10% training speed improvement while maintaining stable scaling to tens of trillions of tokens.

To further leverage reinforcement learning at scale, the team developed an asynchronous RL framework capable of training Qwen3.5 models across all sizes, supporting text-only, multimodal, and multi-turn interaction settings. The system uses a fully disaggregated training–inference architecture, allowing training and rollout generation to run independently while improving hardware utilization, enabling dynamic load balancing, and supporting fine-grained fault recovery. Through techniques such as end-to-end FP8 training, rollout router replay, speculative decoding, and multi-turn rollout locking, the framework increases throughput while maintaining strong consistency between training and inference behavior.

This system–algorithm co-design also constrains gradient staleness and reduces data skew during asynchronous updates, preserving both training stability and model performance. In addition, the framework is built to support agentic workflows natively, enabling uninterrupted multi-turn interactions within complex environments. Its decoupled architecture can scale to millions of concurrent agent scaffolds and environments, which helps improve generalization during training. Together, these optimizations produce a 3×–5× improvement in end-to-end training speed while maintaining strong stability, efficiency, and scalability (Source).

Qwen3.5 Demo

Getting started with Qwen3.5 is very simple. Thanks to the foresight of Qwen Team & their collaborators, their are numerous ways to access and run the Qwen3.5 model suite’s models from your own machine. Of course, running the larger models will require significantly more computational resources. We recommend at least an 8x NVIDIA H200 setup for the larger models in particular, though a single H200 is sufficient for this tutorial. We are going to use Ollama to power Qwen3.5-122B-A10B.

To get started, simply start up a GPU Droplet with an NVIDIA H200 with your SSH key attached, and SSH in using the terminal on your local machine. From there, navigate to the base directory of your choice. Create a new directory with mkdir to represent your new workspace, and change into the directory.

Creating a custom game with Qwen3.5 running on Ollama and Claude Code

For this demo, we are going to do something simple: create a Python based video game for one of the most popular Winter Olympics sports: curling. To get started, paste the following code into the remote terminal:

curl -fsSL https://ollama.com/install.sh | sh
ollama launch claude --model qwen3.5:122b

This will launch Claude Code. If everything worked, it should look like above. From here, we can begin giving instructions to our model to begin generating code!

For this demo, provide it with a base set of instructions. Try customizing the following input:

“I want to create a simple game of curling in python code. i want it to be playable on my computer. Please create a sample Python program.

Packages: pygame”

This will give you, if your model ran predictably, a python file named something like “curling_game.py” with a full game’s code inside. Simply download this file onto your local computer, open the terminal and run it with python3.11 curling_game.py. Our game looks like this:

But looks are deceiving: this game is far from playable in the one-shot state. It requires serious work to amend the code to make the game playable, especially for two players. We can either use Claude Code with Qwen3.5 to make those adjustments, switch to an Anthropic Model like Sonnet 4.6 or Opus 4.6, or make the changes manually. From this base state, it took Qwen3.5 over an hour and at least 10 requests to make the game playable. Time was notably constrained by the single H200 GPU deployment we used for this demo, but the code output leaves significant room for improvement nonetheless. We expect that Opus 4.6 could accomplish the same task in a much quicker time frame, given its optimization for Claude Code, relatively superior benchmark scores, and more optimized infrastructure for inference.

If you want to try it out, this file can be found on Github Gist.

Closing Thoughts

Qwen3.5 VL represents an important step forward for open-source multimodal AI, demonstrating that publicly available models can increasingly rival proprietary systems in capability while offering far greater flexibility for developers. With its scalable architecture, efficient training infrastructure, and strong performance across tasks like coding, document understanding, and computer use, the Qwen3.5 suite highlights the growing maturity of the open AI ecosystem. As tools like GPU Droplets and frameworks such as Ollama make deploying large models easier than ever, vision-language systems like Qwen3.5 are poised to become foundational components in the next generation of AI-powered applications and physical AI systems.

7 OpenClaw Security Challenges to Watch for in 2026

DigitalOcean — Thu, 12 Mar 2026 16:00:00 +0000

This article was originally written by Fadeke Adegbuyi (Manager, Content Marketing)

OpenClaw isn’t just another chatbot wrapper. It executes shell commands, controls your browser, manages your calendar, reads and writes files, and remembers everything across sessions. The project runs locally on your machine and connects to WhatsApp, Telegram, iMessage, Discord, Slack, and over a dozen other platforms via pre-built integrations. It functions as a truly connected personal assistant. As a result, the use cases people have dreamed up for OpenClaw are wild.

One user showed an OpenClaw agent making money on Polymarket by monitoring news feeds and executing trades automatically. Another gave their bot access to home surveillance cameras. Someone else unleashed subagents to apply for UpWork freelancing jobs on their behalf.

// Detect dark theme var iframe = document.getElementById('tweet-2019044317621567811-81'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2019044317621567811&theme=dark" }

But this kind of access to your digital life comes with real consequences when things go wrong. And things have gone wrong. Security researchers found that the agent shipped with serious flaws that made it possible for attackers to hijack machines with a single malicious link. Meanwhile, Moltbook, a Reddit-style platform with over 2.8 million AI agents, had its database completely exposed, so anyone could take control of any AI agent on the platform.

None of this means you should avoid OpenClaw entirely. It means you should understand OpenClaw security challenges and take precautions before spinning up an agent with root access to your laptop. Running OpenClaw in an isolated cloud environment can help neutralize some of these risks—DigitalOcean's 1-Click Deploy for OpenClaw, for example, handles authentication, firewall rules, and container isolation out of the box so your personal machine stays out of the equation.

What are OpenClaw security challenges?

OpenClaw security challenges boil down to a design tension: the tool needs broad system permissions to be useful, but those permissions create a massive attack surface when something goes wrong. The agent runs with whatever privileges your user account has—full disk, terminal, and network access—by design.

It's also agentic and self-improving, meaning it can modify its own behavior, update its memory, and install new skills autonomously. This is impressive from a capability standpoint, but another vector that can cause things to spiral when guardrails are missing. Pair that with defaults that skip authentication, an unvetted skill marketplace, and persistent memory storing weeks of context, and trouble follows. The takeaway: approach with caution, isolate from production systems, and carefully scrutinize the defaults.

To his credit, OpenClaw creator Peter Steinberger has been openly vocal about these risks and actively encourages running OpenClaw in a sandboxed environment, which isolates tool execution inside Docker containers to limit filesystem and process access when the model misbehaves. DigitalOcean's one-click deployment does exactly this out of the box, giving you that isolation without the manual setup.

7 OpenClaw security challenges to watch out for

We've already seen a security audit uncover 512 vulnerabilities (eight critical) and malicious ClawHub skills stealing cryptocurrency wallets. None of these challenges are theoretical. They're all based on incidents that have already played out within weeks of OpenClaw’s launch.

These are the challenges you need to have on your radar if you're experimenting with OpenClaw:

1. One-click remote code execution through WebSocket hijacking

One of the most alarming OpenClaw vulnerabilities discovered so far is CVE-2026-25253, a one-click remote code execution flaw that Mav Levin, a founding researcher at DepthFirst, disclosed in late January 2026. The attack worked because OpenClaw's local server didn’t validate the WebSocket origin header—so any website you visited could silently connect to your running agent. An attacker just needed you to click one link. From there, they chained a cross-site WebSocket hijack into full code execution on your machine. The compromise happened in milliseconds. This is the core danger of running an agent locally on the same machine you're browsing the web with—one careless click and an attacker is already inside.

Levin's proof-of-concept showed that visiting a single malicious webpage was enough to steal authentication tokens and gain operator-level access to the gateway API—giving an attacker access to change your config, read your files, and run commands.

Security checks: In this instance, the fix landed in version 2026.1.29, so update immediately if you’re a version behind. Beyond that, best practices include avoiding running OpenClaw while browsing untrusted sites and considering putting the agent behind a reverse proxy with proper origin validation for an additional layer of protection.

2. Tens of thousands of unprotected OpenClaw instances sitting open on the internet

Here's the thing about OpenClaw's early defaults: the agent trusted any connection from localhost without asking for a password. That sounded fine until the gateway sits behind a misconfigured reverse proxy—at which point every external request got forwarded to 127.0.0.1, and your agent thought the whole internet was a trusted local user. SecurityScorecard's STRIKE team found over 30,000 internet-exposed OpenClaw instances.

Security researcher Jamieson O'Reilly showed just how bad this gets. He accessed Anthropic API keys, Telegram bot tokens, Slack accounts, and complete chat histories from exposed instances, even sending messages on behalf of users and running commands with full admin privileges. No authentication required.

This has since been addressed—gateway auth is now required by default, and the onboarding wizard auto-generates a token even for localhost.

// Detect dark theme var iframe = document.getElementById('tweet-2015401219746128322-801'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2015401219746128322&theme=dark" }

Security checks: At a minimum, check whether your instance is reachable from the public internet. Use a firewall to restrict access, enable gateway token authentication, and never expose the control plane without a VPN or SSH tunnel in front of it. This is a case where a managed cloud deployment can solve the problem outright—because your personal API keys, chat histories, and credentials aren’t sitting on an exposed local machine in the first place.

3. Malicious skills on ClawHub are poisoning the supply chain

ClawHub, OpenClaw's public skill marketplace, lets anyone publish an extension—the only requirement is a GitHub account older than one week. That low bar has unfortunately turned the marketplace into a target. Koi Security audited all 2,857 skills on ClawHub and found 341 that were outright malicious. Bitdefender's independent scan put the number closer to 900 malicious skills, roughly 20% of all packages. A single account—"hightower6eu"—uploaded 354 malicious packages by itself.

The attack is clever. You install what looks like a useful skill and the documentation looks professional. But buried in a "Prerequisites" section, it asks you to install something first—and that something is Atomic Stealer (AMOS), a macOS credential-stealing malware.

Security checks: OpenClaw has since partnered with VirusTotal to scan new skill uploads, but Steinberger himself admitted this isn't a silver bullet. At a minimum, before installing any skill, read its source code. Check the publisher's account age and history. Put simply, treat every skill as untrusted code running with your agent's full permissions. Unlike some exposure risks, malicious skills are a threat regardless of where OpenClaw runs—a poisoned skill executes the same way on a cloud server as it does on your laptop.

4. Credential storage in plaintext and API key leakage

One of the less glamorous but more dangerous issues is how OpenClaw handles secrets. The platform stores credentials in plaintext—including API keys for your LLM provider and tokens for every messaging platform your agent connects to—and those become targets the moment your instance is accessible to anyone other than you. Prompt injection attacks can also trick the agent into exfiltrating credentials by embedding hidden instructions in content the agent processes.

Cisco's team tested a skill called "What Would Elon Do?" and surfaced nine security findings, two of them critical. The skill instructed the bot to execute a curl command sending data to an external server controlled by the skill's author. Functionally, it was malware hiding behind a joke name.

Security check: At a minimum, rotate your API keys regularly and store secrets using environment variables or a dedicated secrets manager rather than config files. It's also worth setting spending limits on your LLM provider accounts. That way, even if a key is compromised, it can't rack up thousands in charges.

5. Prompt injection attacks amplified by persistent memory

What makes prompt injection in OpenClaw worse than in a typical chatbot is the persistent memory. The agent retains long-term context, preferences, and conversation history across sessions—which is one of its best features. But it also means a malicious instruction embedded in a website, email, or document doesn't have to execute immediately. Palo Alto Networks warned that these become "stateful, delayed-execution attacks". A hidden prompt in a PDF you opened last Tuesday could sit dormant in the agent's memory until a future task triggers it days later.

Security check: There's no perfect fix for prompt injection right now; it's an unresolved problem in agentic AI. But you can reduce the blast radius by limiting what tools and permissions your agent has access to, segmenting its access to sensitive systems, and reviewing its memory and context periodically for anything unexpected.

6. Shadow AI spreading through enterprise networks

This one's for anyone working at a company where developers tinker on their work machines. Token Security found that 22% of their enterprise customers have employees running OpenClaw as shadow AI without IT approval. Bitdefender confirmed the same, showing employees deploying agents on corporate machines connected to internal networks. An OpenClaw agent on a developer's laptop with VPN access to production means every vulnerability above is now a business problem.

Security check: If you're on a security team, you should scan your network for OpenClaw instances now. Set up detection for its WebSocket traffic patterns, and mandate that any approved use runs in an isolated environment—a VM or cloud server—rather than on laptops with internal access. Giving teams an approved, isolated deployment path is the fastest way to get ahead of shadow AI—it's much easier to enforce guardrails when the alternative isn't 'don't use it at all.'

7. The Moltbook database breach exposing millions of agent credentials

The security mess isn't limited to OpenClaw itself. Moltbook, the social network for AI agents built by Matt Schlicht, suffered a database exposure that cybersecurity firm Wiz discovered in early February. The database had zero access controls. Anyone who found it could view 1.5 million API tokens, 35,000 email addresses, and private messages between agents—enough to take control of any agent on the platform. China's Ministry of Industry and Information Technology issued a formal warning about OpenClaw security risks, citing incidents like this breach.

Security check: If you've used Moltbook, rotate every API key and token associated with your agent. Treat third-party platforms in the OpenClaw ecosystem with the same skepticism you'd apply to any new service asking for your credentials and consider additional security checks.

Any references to third-party companies, trademarks, or logos in this document are for informational purposes only and do not imply any affiliation with, sponsorship by, or endorsement of those third parties.

Pricing and product information accurate as of February 2026.

GPU Programming for Beginners: ROCm + AMD Setup to Edge Detection

DigitalOcean — Tue, 10 Mar 2026 16:00:00 +0000

In this hands-on tutorial, we demystify GPU computation and show you how to write your own GPU programs from scratch. Understanding GPU programming is essential for anyone looking to grasp why AI models depend on this specialized hardware.

We'll use ROCm and HIP (AMD's version of CUDA) to take you from zero to running real GPU code, culminating in a computer vision edge detector that processes images in parallel.

You can find the code in the project repository: https://github.com/oconnoob/intro_to_rocm_hip/blob/main/README.md

👇 WHAT YOU'LL LEARN IN THIS VIDEO 👇

🔧 Getting Set Up with ROCm Two ways to get started: spin up a GPU Droplet on DigitalOcean with ROCm pre-installed, or install ROCm yourself on an Ubuntu system with an AMD GPU. We cover both methods step-by-step.

➕ Example 1: Vector Addition (The Basics) Learn the fundamental structure of GPU programs—kernels, threads, blocks, and memory management. We'll add one million elements in parallel and verify our results.

⚡ Example 2: Matrix Multiplication (Why Libraries Matter) Discover why optimized libraries like rocBLAS dramatically outperform naive implementations. This is the operation powering most AI models you use daily.

👁️ Example 3: Edge Detection with Sobel Filter (The Cool Stuff) Apply your GPU programming skills to a real computer vision problem—detecting edges in images using a classic Sobel filter, all running massively parallel on the GPU.

Whether you're an AI enthusiast wanting to understand the hardware layer or a developer looking to harness GPU compute power, this tutorial gives you the foundation to start writing efficient parallel programs.

February 2026 DigitalOcean Tutorials: Claude 4.6 and AI Agents

Jess Lulka — Thu, 05 Mar 2026 17:00:00 +0000

Whether you’ve found yourself exploring Anthropic’s latest Claude Opus 4.6 release or following along with the OpenClaw frenzy, DigitalOcean has tutorials and guides to help you get the most out of the latest AI advancements.

These 10 tutorials from last month cover AI agent development, RAG troubleshooting, CUDA performance tuning, and OpenClaw on DigitalOcean. Bookmark them for later or keep them open among your 50 browser tabs to come back to.

What’s New With Claude Opus 4.6

Claude Opus 4.6’s agentic coding model feels less like a coding assistant and more like a collaborative engineer. Developers now have a massive 1M-token context window, which lets the model reason across entire codebases, docs, and long workflows without constantly re-prompting. This means faster refactors, more reliable debugging, and the ability to make iterative UI or architecture changes with just a few guided prompts. Long context plus agentic planning dramatically reduces the time between the idea and working implementation, especially when the model is directly integrated into your cloud stack.

Self-Learning AI Agents: A High-Level Overview

Self-learning agents follow a fundamental loop: observe, act, get feedback, and improve. For developers, these systems aren’t just prompt-driven. They’re built around policies, reward signals, and evolving memory. We make the concept approachable by showing how you can prototype simple versions with standard Python ML tooling. This tutorial can help you determine whether your agent needs to adapt to changing environments or user behavior. You’ll also get a look at how reinforcement-style learning and persistent memory become essential design choices.

CUDA Guide: Workflow for Performance Tuning

Frustrated by the guesswork involved in GPU optimization? We’ve got a step-by-step guide for you. Learn how to profile first, identify the real bottleneck—memory, compute, or occupancy—and then apply targeted optimizations rather than random tweaks. For developers working with AI or HPC workloads, the biggest win is understanding that most performance gains come from a structured workflow, not exotic kernel tricks. You’ll learn that knowing how to measure, optimize, and re-measure is the only reliable path to predictable CUDA speedups.

A Simple Guide to Building AI Agents Correctly

This tutorial is a production blueprint for agentic systems. It covers why naive agent loops fail—runaway costs, hallucinated tool calls, and silent errors—and provides a modular architecture that includes an orchestrator, structured tools, memory, guardrails, and full observability. The most valuable takeaway for real deployments is the “start with the least autonomy” principle: Use deterministic workflows first, and add agent behavior only where it’s truly needed. You want to treat agents like serious software systems with testing, logging, and permissions, not clever prompt chains to get them running correctly.

Why Your RAG Is Not Working Effectively

If your RAG app feels inaccurate or inconsistent, this tutorial helps you diagnose the real cause; it’s usually retrieval quality, chunking strategy, or missing evaluation rather than the model itself. You’ll walk through concrete fixes like better indexing, query rewriting, and relevance filtering so your system actually returns grounded answers. The key takeaway is that RAG performance is mostly a data-pipeline and retrieval-engineering problem, not an LLM problem.

How to Connect Google to OpenClaw

If you’re looking for how to connect AI assistants to real-time data, this guide shows how to wire external data sources into your agent workflow so it can act on real user content instead of static prompts. The practical win is learning how authentication, connectors, and permissions shape what your agent can safely do in production. You'll learn how to deploy OpenClaw on a DigitalOcean Droplet and connect it to Google services like Gmail, Calendar, and Drive using OAuth authentication.

So You Installed OpenClaw on a DigitalOcean Droplet. Now What?

We’ve penned plenty of resources on how to get started with OpenClaw on DigitalOcean (how to run it and how we built a security-hardened Droplet). This follow-up focuses on moving from a working prototype to a more capable, extensible system. You learn how to layer in new tools, expand automation flows, and structure your project so it scales beyond a demo. The key takeaway is architectural: design your agent environment so new capabilities are plug-and-play rather than requiring rewrites.

Effective Context Engineering to Build Better AI Agents

The prompts you feed your AI agent matter just as much as the model behind it. Instead of cramming everything into a single prompt, this article shows you how to structure memory, retrieval, tool outputs, and task state so the model always sees the right information at the right time. You’ll see how using enough context is your real control surface for agent reliability, latency, and cost. Good context engineering often beats switching to a larger model.

Sliding Window Attention: Efficient Long-Context Modeling

Sliding window attention makes long-context transformers far more practical by limiting how many tokens each position can “see.” Instead of every token attending to every other token (which gets expensive fast), the model focuses on a fixed local window—cutting compute costs from quadratic to linear growth. You’ll get a breakdown of how this works, how modern variants improve positional awareness, and why it’s especially useful for long documents, extended chat histories, or agent memory systems. Smarter attention design—not just bigger models—is what makes long-context AI scalable.

How to Run Open-Weight Nemotron 3 Models on a GPU Droplet

Jess Lulka — Tue, 03 Mar 2026 18:41:16 +0000

This article was original written by Andrew Dugan (Senior AI Technical Content Creator II)

NVIDIA has announced the newest additions to their Nemotron family of models, Nemotron 3. There are three separate models in the Nemotron 3 family that are being released, including Nano, Super, and Ultra, which have 30, 49, and 253 billion parameters respectively with up to 1M tokens in context length. Nano was released in December of 2025, and Super and Ultra are scheduled to be released later in 2026. They are being released on NVIDIA’s open model license, making them available for commercial use and modification and giving you ownership and complete control over generated outputs. Both the weights and training data are open and available on Hugging Face. This tutorial will discuss these models and how to deploy the currently available Nano on a DigitalOcean GPU Droplet.

Key Takeaways

NVIDIA has announced Nemotron 3, a new addition to their Nemotron model lineup. Nemotron 3 consists of three new models, Nano (30B), Super (49B), and Ultra (253B).
As of January, 2026, the smallest model, Nano, is the only one currently available for use. Super and Ultra are scheduled for release later in 2026.
All of the models are open-weight, allowing for open access for commercial use and modification. The models’ architectures employ novel efficiency improvements to increase model throughput.

Model Overviews

The Nemotron 3 models use a Mixture of Experts hybrid Mamba-Transformer architecture that is meant to increase the token generation speed, otherwise known as throughput. This means that the models have fewer layers of self-attention and instead use Mamba-2 (state space model) layers and Mixture-of-Experts (MoE) layers that are computationally less expensive and faster, especially for longer input sequences. This allows the Nemotron 3 models to process longer texts faster while using less memory and resources. Some attention layers are included where needed to keep accuracy as high as possible.

NVIDIA describes each of the three models as optimized for different platforms. Nano provides cost efficiency for targeted agentic tasks without sacrificing accuracy. Super offers high accuracy for multi-agentic reasoning. Ultra maximizes reasoning accuracy.

Nano is the smallest of the three and is comparable to Qwen3-30B and GPT-OSS-20B in performance. It is the only of the three that is available as of January 2026.

Nano can be used for both reasoning and non-reasoning tasks with an option to turn off the reasoning capabilities through a flag in the chat template. Responses will be less accurate if reasoning is disabled in the configuration.

Nano is a hybrid Mixture-of-Experts (MoE) architecture that consists of 23 Mamba-2 and MoE layers and six attention layers, with each MoE layer including 128 experts plus one shared expert. Five experts are activated per token, making 3.5 billion of the 30 billion total parameters active.

Super and Ultra both use LatentMoE and Multi-Token Prediction (MTP) layers that further increase text generation speed. MTP is the ability to predict multiple tokens at once in a single forward pass instead of only predicting a single token. LatentMoE is a novel approach to assigning experts that compresses the input data size each expert needs to process in order to reduce the amount of computation for each token. They use these efficiency savings to increase the number of experts that can be used for each token.

In NVIDIA’s white paperon the release, they describe Super as optimized for workloads like IT ticket automation where collaborative agents handle large-volume workloads. Ultra is the option to use when accuracy and reasoning performance are paramount.

Step 1 - Creating a GPU Droplet

To deploy the Nemotron 3 Nano on a DigitalOcean GPU Droplet, first, sign in to your DigitalOcean account and create a GPU Droplet.

Choose AI/ML-Ready as your image and select an NVIDIA H100. Add or select an SSH Key, and create the DigitalOcean Droplet.

Step 2 - Connecting to Your GPU Droplet

Once the DigitalOcean Droplet is created, you SSH(Secure Shell) into your server instance. Go to your command line and enter the following command, replacing the highlighted your_server_ip placeholder value with the Public IPv4 of your instance. You can find the IP in the Connection Details section of your GPU Instance Dashboard.

ssh root@your_server_ip

You may get a message that reads:

OutputThe authenticity of host 'your_server_ip (your_server_ip)' can't be established.....Are you sure you want to continue connecting (yes/no/[fingerprint])?

If you do, you can type yes and press ENTER.

Step 3 — Installing Python and vLLM

Next, verify you are still in the Linux instance, and install Python.

sudo apt install python3 python3-pip

It may notify you that additional space will be used and ask if you want to continue. If it does, type Y and press ENTER.

If you receive a “Daemons using outdated libraries” message asking which services to restart, you can press ENTER.

After Python has finished installing, install vLLM.

pip install vllm

This package might take a little while to install. After it is finished installing, download the custom parser from Hugging Face.

wget https://huggingface.co/nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16/resolve/main/nano_v3_reasoning_parser.py

The custom parser interprets Nemotron-3 Nano v3’s reasoning and tool-calling markup so vLLM can correctly serve responses and route tool calls.

Step 4 - Serving the Nemotron Model

Specify exactly which model you want to serve using the model’s ID from Hugging Face.

vllm serve --model nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16 \
 --max-num-seqs 8 \
  --tensor-parallel-size 1 \
  --max-model-len 262144 \
  --port 8000 \
  --trust-remote-code \
  --reasoning-parser-plugin nano_v3_reasoning_parser.py \
  --reasoning-parser nano_v3

The max-num-seqs is the maximum number of outputs that can be processed concurrently. You can have up to eight single-output requests processed at a single time in this example.

The tensor-parallel-size is the number of GPUs you are spreading the model across via tensor parallelism. One is equal to a single GPU. The max-model-len is the maximum total tokens per request. trust-remote-code is necessary for Nemotron’s custom chat template and parsing logic.

Finally, the reasoning-parser-plugin and reasoning-parser parameters load and select the custom reasoning parser.

Once the model is loaded and served on your instance with vLLM, you can make inference calls to the endpoint using Python locally or from another server. Create a Python file called example_vllm_request.py and run the following code. Replace your_server_ip with the IP address of your GPU Droplet.

import requests

url = "http://your_server_ip:8000/v1/completions"
data = {
    "model": "nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16",
    "messages": [{"role": "user", "content": "What is the capital of France?"}],
    "max_tokens": 1000
}

response = requests.post(url, json=data)
message = response.json()['choices'][0]['message']['content']
print(message)

You will see output similar to the following:

Output
The capital of France is **Paris**.

If you print out the entire response.json() object, you can view the reasoning tokens. If you would like to run it with reasoning disabled, you can add a chat_template_kwargs parameter to the data object above.

data = {
    "model": "nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-BF16",
    "messages": [{"role": "user", "content": "What is the capital of France?"}],
    "max_tokens": 1000,
    "chat_template_kwargs": {"enable_thinking": False},
}

FAQ

What are the hardware requirements and GPU memory needed to run Nemotron 3 Nano locally?

Nemotron 3 Nano can run on GPUs with at least 60 GB of VRAM in BF16 precision, such as an A100 80 GB or H100. A quantized version may allow it to run on GPUs with less memory.

Can I fine-tune Nemotron 3 Nano on my own data, and what are the licensing implications?

Yes, Nemotron 3 models are released under NVIDIA’s open model license, which permits commercial use, modification, and fine-tuning. You retain complete ownership of any outputs generated and can fine-tune the model on custom datasets for your specific use cases.

What is the difference between the Mixture-of-Experts (MoE) architecture and traditional transformer models in terms of inference cost?

The MoE architecture only activates five out of 128 experts per token (3.5B of 30B parameters), making inference much more efficient than traditional dense models.

Has NVIDIA released other LLMs in the past?

Yes, NVIDIA has released a large number of open models and datasets, including other Nemotron model versions, Megatron, ASR models, and more.

Conclusion

The Nemotron 3 family is a comparatively effective and efficient open model with fast inference and accurate results. The smallest version, Nano, is currently available as of January 2026, and the other two larger versions will become available in coming months.

In this tutorial, you deployed Nemotron 3 Nano on a DigitalOcean GPU Droplet. Next, you can build a workflow that uses it for any data sensitive applications that require a high degree of privacy and control.

Technical Deep Dive: How we Created a Security-hardened 1-Click Deploy OpenClaw

Jess Lulka — Tue, 24 Feb 2026 22:11:29 +0000

This article was originally written by Freddie Rice (Staff Product Security Engineer)

OpenClaw, an open source AI assistant (recently renamed from Moltbot, and earlier Clawdbot), has exploded in popularity over the last few days, and at DigitalOcean we immediately wondered “how can we enable more people to try this new technology safely and easily?” We noticed that there was a lot of interest by folks looking to use this software, but also that there was concern around the security of the open source software, especially when connecting it directly to users’ own machines. We dug in to find a way to deliver this software to our customers as fast as possible, as easily as possible and as safe as possible.

At DigitalOcean, our 1-Click Deploy OpenClaw (formerly 1-Click Deploy Moltbot) through our Marketplace enables us to package the latest and greatest software configured for our Droplet® server, and make it easily available to customers. Creating our 1-Click Deploy OpenClaw was the natural next step in getting this to our customers.

Toying around with OpenClaw on a local machine is fun, but it could severely impact the ability to deploy and use the software for longer term use and may not meet the safe environment that you need. Some of the benefits to deploying on DigitalOcean include:

Always available – the service is available to customers via the web
Easy to connect to it – Droplets have a static ip address
Vertical scalability – scale up CPUs, memory, and disk storage with higher workloads
Cognitive overload – start with basic configs, tweak the ones that matter to you

We made a lot of changes as we built the 1-Click Deploy OpenClaw, but the main elements we focused on were

How do we communicate with the service safely?
How do we keep the agentic code isolated from the rest of the system?
How do we prevent attacks from the wider internet?

All of that while providing a straightforward deployment UX to our customers! Let’s dig in…

Delivering an Image with Safe Defaults

Our priority in creating a 1-Click Deploy OpenClaw on our Droplet was twofold: First, speed, as we wanted to get something out quickly to our users. Second was providing a solution that provided additional security benefits. These are the actions we took to meet those goals:

Keeping deployments consistent (DevOps)

We saw that there are multiple ways to deploy the software – we chose the most consistent path, which was picking a stable release from the Git repository on GitHub, pulling it and building from there.

Why not pull the latest and greatest from main? Changes are happening at a rapid pace, which is awesome for feature development but can come at the expense of stability. Depending on the minute we build our 1-click image, we could get a working version or a broken version.

So we make sure that we can deliver the latest stable version.

TLS (Keep communications safe and auditable)

Once we had a Packer image that we could iterate on, we applied our security best practices for the 1-clicks to set up TLS. This is a crucial step to make sure that our customers can communicate with the bot in a safe way that doesn’t allow eavesdropping.

Our best practices consist of using Caddy as a reverse proxy with a TLS certificate issued by LetsEncrypt. Caddy ensures that the service is deployed externally is the service we want to publish and provides a safe channel with which to serve it. Furthermore, Caddy outputs logs to a location that can be audited after the fact, allowing the end user to see how their service is actually being used.

A new UX improvement we added to this image is seamless TLS configuration with LetsEncrypt via IP addresses without requiring a domain name! While OpenClaw spins up, Caddy is requesting a new certificate on your behalf, no configuration required.

Authz (Gateway Key + Pairing)

How do we know that the requests are coming from you? We have a OpenClaw gateway key in place to make sure that the user who is supposed to use the platform is the correct one.

Next, we leaned into a feature that OpenClaw provides called “Paring” – this exists to make sure that the devices that are going to communicate with the main server are the trusted ones.

Sandboxing (keep safe from Agents)

Part of the configuration is an Anthropic / OpenAI / Model key – these are sensitive pieces of material that are required in order to allow the software to function! So how do we let agents that can run arbitrary code on the machine, not read and abuse these tokens?

Furthermore, how do we stop the agents from potentially destroying the machine itself?

Luckily, there is a configuration available that puts the agent deployments into their own containers. If an agent blows up, it will destroy its own ephemeral docker container, but the host filesystem will still be safe from incorrect agentic modifications.

Safe Defaults

These boxes are taking the best configurations that we implement for all of our 1-clicks, including but not limited to:

Fail2ban – Make sure that the background noise of the internet doesn’t cause disruptions to your droplet. It does this by monitoring the logs of failed requests to the system and dynamically updating firewall rules to block known bad patterns on the internet.

Unattended upgrades – We want to make sure that your Droplet is always up to date. We have Ubuntu configured with unattended upgrades that periodically will check for vulnerable packages and automatically patch them.

Deployment Constraints and Upcoming Features

To ensure a stable and repeatable installation, we utilize Packer for our image provisioning; however, during testing, we found that smaller Droplet configurations consistently encountered out-of-memory errors during the snapshot creation process. While this currently necessitates a minimum $24/month Droplet size to match the snapshot’s disk and memory requirements, we chose to prioritize getting this tool into your hands today rather than delaying for further optimization. We are already iterating on the image to reduce its footprint and support lower-cost tiers, and in the spirit of transparency, we have made our Packer scripts public so you can audit the provisioning process and gain confidence in the one-click experience. We are also working to quickly add support for all DigitalOcean Gradient AI models, including OpenAI, add auto provisioning of Gradient AI API Key and injecting for the user, and more updates as OpenClaw evolves over time.

After deploy (make it yours!)

1-Click Deploy OpenClaw is a great launch point, but OpenClaw is infinitely customizable once up and running in the Droplet. Choose which messaging platforms are the best fit for your workflows, and get chatting.

Get started with the 1-Click Deploy OpenClaw

Get started with the 1-Click Deploy OpenClaw by visiting the Marketplace, and follow this tutorial for step by step instructions on how to get started.

4 AI Models (That aren’t Opus 4.6) on Our Minds This Week

Jess Lulka — Mon, 23 Feb 2026 19:59:44 +0000

So many models, so little time. Today, we’re bringing our attention to some super cool releases from Qwen, MiniCPM-o, ACE-Step, and GLM-OCR. So what can these models do?

Qwen3-Coder-Next: An open-weight model built for coding agents and local development that speeds up deployments just as well as more compute-hungry models. By activating just 3B parameters out of 80B total, the model can rival models that require far more compute, making large-scale deployment markedly more economical. The model is also trained for durable agent behavior, including long-horizon reasoning, sophisticated tool use, and recovery from failed executions, and, with a 256k context window plus flexible scaffold support, is designed to integrate smoothly into a wide range of existing CLI and IDE workflows.
MiniCPM-o 4.5: A game-changer for vision performance. The most advanced release in the MiniCPM-o line, packaging a 9B-parameter end-to-end architecture derived from SigLip2, Whisper-medium, CosyVoice2, and Qwen3-8B while adding full-duplex multimodal streaming. The model delivers leading vision performance that rivals or surpasses much larger proprietary systems, supports unified instruction and reasoning modes, and enables natural bilingual real-time speech with expressive voices, cloning, and role play. A major addition is simultaneous video/audio input with concurrent text and speech output, allowing the system to see, listen, talk, and even act proactively in live scenarios. It further strengthens OCR and document understanding, handles high-resolution images and high-FPS video efficiently, supports 30+ languages, and is easy to deploy across local and production environments through broad tooling, quantization options, and ready-to-run inference frameworks.
ACE-Step 1.5: An open-source and legally compliant music foundation model built to deliver commercial-grade generation on everyday hardware, enabling creators to safely use outputs in professional projects. Trained on a large, legally compliant mix of licensed, royalty-free, and synthetic data, the system can produce complete songs in seconds while running locally on GPUs with under 4GB of VRAM. Its hybrid design uses a language model as an intelligent planner that turns prompts into detailed musical blueprints—covering structure, lyrics, and metadata—which are realized by a diffusion transformer, aligned through intrinsic reinforcement learning rather than external reward models. Beyond raw synthesis, ACE-Step v1.5 supports fine stylistic control, multilingual prompting, and flexible editing workflows such as covers, repainting, and vocal-to-instrumental conversion.
GLM-OCR: A multimodal system for advanced document understanding built on the GLM-V encoder–decoder framework. To boost learning efficiency, accuracy, and transferability, it incorporates Multi-Token Prediction (MTP) objectives together with a stable, end-to-end reinforcement learning strategy across tasks. The architecture combines a CogViT visual backbone pre-trained on large image-text corpora, a streamlined cross-modal bridge that aggressively downsamples tokens for efficiency, and a GLM 0.5B language decoder for text generation. Paired with a two-stage workflow, layout parsing followed by parallel recognition using PP-DocLayout-V3, the model achieves reliable, high-fidelity OCR results across a wide spectrum of complex document structures.

They may not have the marketing dazzle of Anthropic’s flagship model, but these four have an incredible amount of potential to help clear some vexing development issues. What models are you keeping an eye on? Add them in the comments.

How to Lower Your AI Costs When Scaling Your Business

Jess Lulka — Fri, 20 Feb 2026 20:31:09 +0000

As AI adoption grows, technological maintenance isn’t the only component you need to keep up with; your budget also requires a watchful eye. Especially when inference workloads can scale data—and costs—quickly. Your AI inference bill comes down to three things: the hardware you use, the scale you need, and how fast it generates output.

If you’re curious how you can lower LLM inference spending, here are three tips to reduce your overall AI costs as you scale:

1. Diversify your hardware

Hardware is a major reason AI has historically been expensive: the only processing units available to run these workloads are GPUs, and demand exceeded supply (driving up costs). This is true for consumer-grade GPUs, where it's not uncommon to see prices two or three times above MSRP, and data center GPU scarcity is even worse.

For a long time, NVIDIA held a large market share with its physical hardware and compute unified device architecture (CUDA)-only frameworks. AMD has since introduced open-source ROCm and made it easier for teams to expand the hardware types they can use for their AI workloads, increasing GPU supply and reducing vendor lock-in.

2. Configuration (Model + KV cache) and quantization

When running LLM inference, pay attention to GPU capacity and speed, as they affect overall performance. You need a minimum amount of memory to even load and run a model. Additional capacity beyond that allows you to have a bigger KV cache, which is critical to high-throughput performance; the KV cache stores the history of each conversation for each user that the GPU is currently serving. Without it, your token generation becomes slower, and inference speed slows down. With it, you can serve more users at once and keep token generation steady.

Beyond using a KV cache and optimizing your model, consider quantization. This practice reduces precision, so less memory (or VRAM) is required to store tokens. A 5000-token conversation, for example, will take several gigabytes of GPU memory (VRAM) to store. These gigabytes contain a massive amount of numbers that the GPU reuses during inference. Each of these numbers requires 2 bytes of memory when using the default 16-bit precision. With 8-bit precision, you only need 1 byte to store the same number of tokens and reduce the overall memory requirements by half. Though your hardware must support 8-bit models for this to work effectively.

3. Optimize your parallelism setup

AI production workloads are massive and require gigabytes (or even terabytes) to just load models. Even if you could load a single model onto a GPU that supports 8-bit models, there’s no guarantee that you would be able to successfully have enough memory to run your model and associated activations (calculations the LLM does during inference) on just one GPU. This is where tensor parallelism and data parallelism improve performance.

When you spread your LLM models across multiple GPUs, you reduce the overall calculations (and memory) required per GPU, leaving plenty of room for activations and the KV cache. If you choose to apply this technique, consider the technical overhead of GPU data coordination and synchronization.

If you’re curious to see a practical application of these techniques, you can read our full Character.ai case study for a technical deep dive. With these workflows in place, the company reduced its inference costs by 50% while continuing to support an app with 10s of millions of users.

How to Run OpenClaw with DigitalOcean

Jess Lulka — Tue, 10 Feb 2026 18:45:07 +0000

OpenClaw (formerly known as Moltbot and Clawdbot) is an open-source, self-hosted personal AI assistant that can run directly on your computer. It can execute a variety of tasks, such as managing your calendar, browsing the web, organizing files, managing your email, and running terminal commands. It supports any Large Language Model (LLM), and you can communicate with it through standard chat apps that you already use like WhatsApp, iMessage, Telegram, Discord, or Slack.

While it is technically possible to run OpenClaw on your local machine, security concerns arise when giving an AI agent open access to your computer with all of your personal data on it. A better approach is to deploy it on a separate machine specifically for OpenClaw or to deploy it on a cloud server.

There are 3 ways to deploy OpenClaw with DigitalOcean. You can either deploy yourself on a DigitalOcean Droplet, deploy with a pre-built 1-Click Application in the Droplet Marketplace, or use the DigitalOcean App Platform. Each of these options will have different security and maintenance considerations, so choose an option based on your app’s needs.

When to choose each deployment option

Bare DigitalOcean Droplet: Deploy directly on a DigitalOcean Droplet only if you require full control over server configuration and are comfortable managing security hardening manually.
1-Click Application: A 1-Click Application is best for solo developers who want improved security benefits with a fast, self-contained deployment with maximal control, and minimal abstraction. This requires minimal decisions and setup. It is a great option for fast experimentation, but it is not as scalable as the App Platform option.
App Platform: The App Platform is best for teams with a production-level deployment that requires long-term operational maturity. For example, if you need to scale quickly (horizontal auto-scaling), need operational consistency with automatic restarts, zero-downtime deploys, or sleep mode requirements for cost optimization.

Both the 1-Click Application and the App Platform deployment options will be covered in this tutorial below. If you prefer to manually deploy OpenClaw on a DigitalOcean Droplet without a 1-Click Application or the App Platform, you can follow the Quickstart Guide.

The DigitalOcean 1-Click and App Platform deployments handle many of the security best practices for you automatically. These security enhancements include:

Authenticated communication: Droplets generate an OpenClaw gateway token, so communication with your OpenClaw is authenticated, essentially protecting your instance from unauthorized users.
Hardened firewall rules: Droplets harden your server with default firewall rules that rate-limit OpenClaw ports to prevent inappropriate traffic from interfering with your OpenClaw use and to help prevent denial-of-service attacks.
Non-root user execution: Droplets run OpenClaw as a non-root user on the server, limiting the attack surface if an inappropriate command is executed by OpenClaw.
Docker container isolation: Droplets run OpenClaw inside Docker containers on your server, setting up an isolated sandbox and further preventing unintended commands from impacting your server.
Private DM pairing: Droplets configure Direct Message (DM) pairing by default, which prevents unauthorized individuals from being able to talk to your OpenClaw.

While deploying this way on a cloud server offers security benefits, OpenClaw is still quite new. Like many new tools, it might have architectural characteristics that have not been designed to work with additional security features yet. Therefore, with added security features, some of OpenClaw’s functionality may not function as perfectly as it was intended. For example, some skills might not work out-of-the-box and can require some additional manual set up.

Key Takeaways

OpenClaw is a powerful, self-hosted AI assistant that can execute tasks like managing calendars, browsing the web, and running terminal commands. It should not be run on your personal machine due to significant security risks associated with giving an AI agent high-level system access.
Deploying OpenClaw on a DigitalOcean 1-Click Application or on the App Platform provides a safer environment through security features like authenticated communication, hardened firewall rules, non-root user execution, Docker container isolation, and private Direct Message (DM) pairing.
OpenClaw is model-agnostic and supports various LLMs via Application Programming Interface (API) keys or local deployment, making it flexible for different use cases and preferences.

In this tutorial, you will first deploy an OpenClaw instance onto DigitalOcean’s 1-Click Deploy OpenClaw. Then you will deploy an instance on the App Platform. If you only need to be able to deploy on the App Platform, skip ahead to that section below.

1-Click Application

Step 1 — Creating an OpenClaw Droplet

First, sign in to your DigitalOcean account and create a Droplet. On the Create Droplets page in the DigitalOcean Control Panel, under Region, select the region closest to you. Under Choose an Image, select the Marketplace tab.

In the search bar, type OpenClaw and select the OpenClaw image from the search results.

Next, choose a Droplet plan. The Basic plan with at least 4GB of RAM (such as the s-2vcpu-4gb size) is recommended for running OpenClaw effectively.

Under Authentication, select SSH Key and add your SSH key if you haven’t already. If you need to create an SSH key, follow the instructions in How to Add SSH Keys to New or Existing Droplets.

Finally, give your Droplet a hostname (such as OpenClaw-server), and click Create Droplet.

Alternatively, you can create an OpenClaw Droplet using the DigitalOcean API. To create a 4GB OpenClaw Droplet in the NYC3 region, use the following curl command. You’ll need to either save your API access token to an environment variable or substitute it into the command:

curl -X POST -H 'Content-Type: application/json' \
     -H 'Authorization: Bearer '$TOKEN'' -d \
    '{"name":"choose_a_name","region":"nyc3","size":"s-2vcpu-4gb","image":"openclaw"}' \
    "https://api.digitalocean.com/v2/droplets"

Once your Droplet is created, it takes a few minutes to fully initialize. After initialization, you can SSH into your Droplet using the IPv4 address shown in your DigitalOcean dashboard:

ssh root@your_droplet_ip

Replace your_droplet_ip with your Droplet’s actual IP address.

Once logged in, the OpenClaw installation will be ready to configure. The DigitalOcean 1-Click Deploy OpenClaw includes OpenClaw version 2026.1.24-1 pre-installed with all necessary dependencies.

You will see a welcome message from OpenClaw. Under the Control UI & Gateway Access section, you will see a Dashboard URL. Note the Dashboard URL value. You will use it later to access the GUI in your browser.

You will see a welcome message from OpenClaw. Under the Control UI & Gateway Access section, you will see a Dashboard URL. Note the Dashboard URL value. You will use it later to access the GUI in your browser.

Within the terminal, choose Anthropic as your AI Provider. If you have access to Gradient AI, you can select that option. OpenAI models will be available soon. Once you select your provider, provide the respective API/Secret key.

Step 2 — Using OpenClaw

With the 1-Click Application, there are 2 ways to use OpenClaw: you can either use the Graphical User Interface (GUI) through your browser, or you can use the Text User Interface (TUI) through your terminal.

After entering your API key, it may ask if you want to run pairing automation now. This pairing is to give you access to the UI dashboard (GUI). If you would like to use the GUI, you can type yes and enter.

It will then provide you with a url. Open a browser, and in the URL bar, paste the provided URL from OpenClaw. This will open an OpenClaw GUI directly in your browser using the Gateway token to authenticate you for additional security. You will then need to go back to the terminal, type continue, and press enter to continue the automated pairing.

In your browser, click refresh, and you will be directed to the default chat page.

Here you can type a message and send, and OpenClaw will respond. For example, if you ask about what files it can see, it will tell you.

Input
What files can you currently see on my computer?

Output
Here’s a list of the files and directories currently visible in the sandbox workspace:
.
├── AGENTS.md
├── BOOTSTRAP.md
├── HEARTBEAT.md
├── USER.md
└── skills
    ├── 1password
    │   ├── SKILL.md
    │   └── references
...

From the GUI, you can review the bot’s usage, add communication channels, schedule cron jobs, add skills, and manage all aspects of OpenClaw.

To use the TUI, run the following command:

/opt/openclaw-tui.sh

Note: Depending on the version, the script may also be located at /opt/clawdbot-tui.sh.

You’ve now successfully deployed OpenClaw on DigitalOcean and accessed it through a web browser. From here, you can explore additional OpenClaw capabilities, such as browsing the web, managing files, or executing terminal commands on your Droplet.

Step 3 - Installing Skills with the 1-Click Application

OpenClaw comes with over 50 skills automatically loaded in the skill registry. You can install skills in the GUI by navigating to the Skills section in the browser dashboard. For example, to integrate with Google Calendar, search for calendar, and click on Install.

A large number of skills are available to perform a wide range of tasks including managing your files, automating web browsing, monitoring health and smart home technologies, and managing social media communication. Read through What is OpenClaw? for an overview of how OpenClaw works and what OpenClaw’s capabilities are.

App Platform

Step 1 - Creating the OpenClaw App

Deploying through DigitalOcean’s App Platform follows a slightly different process. First, go to the OpenClaw App Platform repo and click on the Deploy to Digital Ocean button.

Add your model access key to the GRADIENT_API_KEY parameter. This will allow you to use your Gradient AI Serverless Inference account for the OpenClaw bot. Finally, click on Create APP. It can take up to 5 minutes to finish building the app.

After it has finished building, go to the Console tab of the app, and confirm it is working by typing in:

openclaw gateway health --url ws://127.0.0.1:18789

You now have a working OpenClaw App. If you would like to connect to it remotely, you will need to install and configure doctl, the official command line interface (CLI) for the DigitalOcean API. You will need to follow the instructions to create an API token, use the API token to grant account access to doctl, then use the doctl apps console command to initiate a console session for the app. This step is not completely necessary because you can just use the Console in your application through the DigitalOcean website.

Step 2 - Connecting OpenClaw to WhatsApp

When you initiate the console session, you will be accessing it as the root user. So first, you need to change to the openclaw user:

su openclaw

Then you need to change directories into the home directory of the openclaw user:

cd

Note: The cd command without arguments changes to the current user’s home directory. Since you’re now the openclaw user, this will navigate to /home/openclaw.

To connect your OpenClaw application to WhatsApp, go to the Console of your OpenClaw application enter the following command:

openclaw channels login --channel whatsapp

Follow the instructions to scan the QR code and connect with your bot through WhatsApp.

Step 3 - Installing Skills with the App Platform Application

To install skills through the App Platform application, from the openclaw user in the console, browse skills with the following command:

openclaw skills

Find a skill that you would like to use and install it with the following command, replacing skill_name with the name of the skill you would like to install:

npx clawhub install <skill_name>

You now have an OpenClaw App Platform application with a WhatsApp connection and skills. You can execute the openclaw command to access the rest of openclaw’s features.

FAQ

Can I use a model other than Claude?

Yes, OpenClaw is designed to be model-agnostic, so it does support models other than Anthropic’s Claude. It allows users to use various Large Language Models (LLMs) via API keys or locally. However, note that using the DigitalOcean 1-Click Deploy OpenClaw as outlined above, most users will only be able to use Anthropic (support for OpenAI coming soon!).

Can I deploy it on other operating systems that are not Linux?

Yes, you can deploy OpenClaw on Windows, macOS, and Linux, and other platforms.

What are the main security concerns?

The main security concerns are its high-level system access, potential for misconfiguration, and its ability to execute arbitrary code that might be harmful to your system. It’s important to be aware of the environment in which it’s deployed and the access it has.

How do I give API Key access to my Agents?

It is possible to selectively give agents more control over the world around you. The default OpenClaw application will keep these keys together in an environment that is available to all agents. This configuration gives you control to inject the keys you want to the agents that should have those powers. On the “Agents” Menu bar, select the Agent you’d like to grant access (or “Defaults” for all), then under Sandbox > Docker > Env, add the selected API Keys that should be used.

How does pricing work with OpenClaw?

OpenClaw is free and open-source to download and use, but you are paying for the LLM tokens. Therefore, the price depends on your usage. You should be careful with this because with scheduled jobs or other functionality, the costs can increase quickly and unexpectedly.

Conclusion

In this tutorial, you deployed OpenClaw on DigitalOcean, creating a secure environment for your personal AI assistant. By running OpenClaw on a cloud server instead of your local machine, you’ve significantly reduced security risks while maintaining the full functionality of this powerful tool.

The DigitalOcean OpenClaw deployment provides critical security features out of the box—including authenticated communication, hardened firewall rules, Docker container isolation, and non-root user execution—that make it safer to experiment with AI agent capabilities. You accessed it through a web browser and can now execute various tasks through your preferred messaging apps. Next, try adding new skills to your OpenClaw instance and customize the app to best suit your agentic needs.

Forem: DigitalOcean

Build an End-to-End RAG Pipeline for LLM Applications

Key Takeaways

Understanding the RAG System Architecture

Data Ingestion in a RAG Pipeline

Text Chunking: Preparing Documents for Retrieval

Embedding Generation

Vector Embedding

Storing Vectors in a Database

Retrieval in a RAG Pipeline

Generation with a Large Language Model

Code Demo: Building a Simple End-to-End RAG Pipeline

Install dependencies

Load documents

Split documents into chunks

Generate embeddings

Store vectors

Retrieval and generation

Evaluating RAG System Performance

Scaling and Production Considerations

Cost and Latency Optimization

RAG vs Fine-Tuning

Conclusion

Resources

Tutorial: Deploy NVIDIA's NemoClaw in One Click

Key Takeaways

Prerequisites

Step 1 - Create a Droplet from the Marketplace

Step 2 - SSH into the Droplet

Step 3 - Walk Through the Onboard Wizard

Sandbox Name

NVIDIA API Key

Policy Presets

Step 4 - Connect to NemoClaw

Reconnecting After a New SSH Session

What's Next

Resources

GPT 5.3 Codex is the Next Level for Agentic Coding

Key Takeaways

GPT‑5.3‑Codex Overview

Getting Started with GPT-5.3-Codex

Vibe Coding a Z-Image-Turbo Web Application with GPT‑5.3‑Codex

Closing Thoughts

Getting Started with Qwen3.5 Vision-Language Models

Key Takeaways

Qwen3.5: Overview

Qwen3.5 Demo

Creating a custom game with Qwen3.5 running on Ollama and Claude Code

Closing Thoughts

7 OpenClaw Security Challenges to Watch for in 2026

What are OpenClaw security challenges?

7 OpenClaw security challenges to watch out for

1. One-click remote code execution through WebSocket hijacking

2. Tens of thousands of unprotected OpenClaw instances sitting open on the internet

3. Malicious skills on ClawHub are poisoning the supply chain

4. Credential storage in plaintext and API key leakage

5. Prompt injection attacks amplified by persistent memory

6. Shadow AI spreading through enterprise networks

7. The Moltbook database breach exposing millions of agent credentials

GPU Programming for Beginners: ROCm + AMD Setup to Edge Detection

February 2026 DigitalOcean Tutorials: Claude 4.6 and AI Agents

How to Run Open-Weight Nemotron 3 Models on a GPU Droplet

Key Takeaways

Model Overviews

Step 1 - Creating a GPU Droplet

Step 2 - Connecting to Your GPU Droplet

Step 3 — Installing Python and vLLM

Step 4 - Serving the Nemotron Model

FAQ

Conclusion

Related Links

Technical Deep Dive: How we Created a Security-hardened 1-Click Deploy OpenClaw

Delivering an Image with Safe Defaults

Keeping deployments consistent (DevOps)

TLS (Keep communications safe and auditable)

Authz (Gateway Key + Pairing)

Sandboxing (keep safe from Agents)

Safe Defaults

Deployment Constraints and Upcoming Features

After deploy (make it yours!)