DEV Community: Manish Shivanandhan

Getting Started with Terraform: From Zero to Production

Manish Shivanandhan — Mon, 13 Apr 2026 09:28:54 +0000

Infrastructure has undergone a fundamental shift over the past decade.

What was once configured manually through dashboards and shell access is now defined declaratively in code. This shift is not just about convenience. It is about repeatability, auditability, and control.

Terraform sits at the center of this transformation. It allows you to define infrastructure using configuration files, apply those configurations consistently across environments, and evolve systems safely over time.

For teams building modern applications, especially on platform abstractions, Terraform becomes the control plane for everything from application deployment to databases and networking.

The Terraform provider from Sevalla extends this model by allowing teams to manage the entire application platform as code, not just underlying infrastructure. It enables you to define applications, databases, networking, storage, and deployment workflows in a single, unified configuration.

Instead of stitching together multiple tools or relying on manual setup, everything from code deployment to traffic routing and environment configuration can be expressed declaratively. This creates a consistent, repeatable system where environments can be replicated easily, changes are version-controlled, and production setups can evolve safely over time.
This article walks through how to go from zero to a production-ready setup using Terraform and the Sevalla Terraform Provider, focusing on practical concepts rather than theory.

What Terraform Actually Does

Terraform is an infrastructure-as-code tool that translates configuration files into real infrastructure. You describe the desired state of your system, and Terraform figures out how to achieve it.
At a high level, Terraform operates in three phases.
First, it initializes the working directory and downloads required providers. Providers are plugins that allow Terraform to interact with specific platforms.
Next, it creates an execution plan. This plan shows what resources will be created, modified, or destroyed to match your configuration.
Finally, it applies the plan, making the necessary API calls to bring your infrastructure into the desired state.
The key idea is that Terraform is declarative. You define what you want, not how to do it. Terraform handles the orchestration.
This abstraction becomes extremely powerful as systems grow more complex.

Setting Up Terraform for the First Time

Getting started with Terraform requires very little setup. You install the CLI, create a working directory, and define a basic configuration.
A Terraform configuration is written in HCL, a domain-specific language designed to be human-readable. Even a simple configuration establishes the core concepts.
You define the required provider, configure authentication, and declare resources.
Here is a minimal example that provisions an application using a managed platform provider.

terraform {
 required_providers {
   sevalla = {
     source  = "sevalla-hosting/sevalla"
     version = "~> 1.0"
   }
 }
}

provider "sevalla" {
}
data "sevalla_clusters" "all" {}
resource "sevalla_application" "web" {
 display_name = "my-web-app"
 cluster_id   = data.sevalla_clusters.all.clusters[0].id
 source       = "publicGit"
 repo_url     = "https://github.com/example/app"
}

This configuration does several things.
It declares the provider, which tells Terraform how to communicate with the platform. It fetches available clusters using a data source. It defines an application resource that points to a Git repository.
Even at this stage, you are already defining infrastructure in a reproducible way.
To execute this configuration, you run three commands.
You initialize the project, generate a plan, and apply it.

export SEVALLA_API_KEY="your-api-key"
terraform init
terraform plan
terraform apply

After applying, your application is deployed without manual steps.

Understanding Providers, Resources, and Data Sources

Terraform revolves around three core constructs.
Providers act as the bridge between Terraform and external systems. They expose APIs in a structured way that Terraform can use.
Resources represent the infrastructure you want to create. These are the building blocks of your system. Applications, databases, load balancers, and storage buckets are all modeled as resources.
Data sources allow you to query existing infrastructure. Instead of creating something new, you retrieve information that can be used elsewhere in your configuration.
The combination of these constructs allows you to build flexible and composable systems.
For example, you can fetch a list of available clusters using a data source and then dynamically assign your application to one of them. This reduces hardcoding and improves portability.
As your configuration grows, these abstractions help you maintain clarity and structure.

Building a Real Application Stack

A production system is rarely just a single application. It typically includes multiple components that need to work together.
With Terraform, you can define the entire stack in one place.
You might start with an application, then add a managed database, connect them internally, and expose the application through a load balancer.
A simplified flow looks like this.
You define the application resource that pulls code from a repository. You provision a database resource, such as PostgreSQL or Redis. You establish an internal connection between the application and the database. You configure environment variables for credentials. You optionally add a custom domain or routing layer.
Each of these components is a resource, and Terraform ensures they are created in the correct order.
This approach eliminates configuration drift. Instead of manually setting up each component, everything is defined in code and version-controlled.
It also makes environments consistent. Your staging and production setups can be identical except for a few variables.

Managing Configuration and Secrets

Production systems require configuration. This includes environment variables, API keys, and connection strings.
Terraform provides multiple ways to handle this.
You can define variables in your configuration and pass values at runtime. Sensitive values, such as API keys, are typically injected via environment variables.
For example, authentication is handled through an API key that can be set as an environment variable.

export SEVALLA_API_KEY="your-api-key"

This avoids hardcoding credentials in configuration files.
You can also define environment variables as part of your infrastructure. This allows you to configure applications consistently across environments.
The important principle is separation of concerns. Infrastructure definitions should remain clean, while sensitive data is managed securely.

Scaling and Process Configuration

Modern applications often consist of multiple processes. A web server handles incoming requests, background workers process jobs, and scheduled tasks run periodically.
Terraform allows you to define these processes explicitly.
You can configure different process types, allocate resources, and scale them independently. This is particularly useful for handling variable workloads.
For example, you might scale web processes based on incoming traffic while keeping background workers at a steady level.
By defining this in code, scaling becomes predictable and repeatable.
You avoid manual intervention and ensure that your system behaves consistently under load.

Adding Networking and Traffic Management

As systems grow, managing traffic becomes more important.
Terraform enables you to define networking components such as load balancers and routing rules. You can map domains to applications, distribute traffic across multiple services, and control access.
This is essential for production readiness.
A load balancer can improve availability by distributing traffic across instances. Domain configuration ensures that users can access your application through a stable endpoint.
You can also define restrictions, such as IP allowlists, to enhance security.
All of this is managed declaratively, which reduces the risk of misconfiguration.

Pipelines and Continuous Deployment

Production systems require reliable deployment workflows.
Terraform can be used to define deployment pipelines and stages. This allows you to model how code moves from development to production.
You can define multiple stages, associate applications with each stage, and control how deployments are triggered.
This brings infrastructure and deployment logic into a single system.
Instead of relying on external scripts or manual processes, everything is defined in a structured and version-controlled way.
It also improves traceability. You can see exactly how a system is configured and how changes are applied over time.

From Configuration to Production

Moving from a simple setup to production involves more than just adding resources. It requires discipline in how you manage infrastructure.
Version control becomes critical. Every change to your infrastructure should go through code review. This reduces the risk of introducing breaking changes.
State management is another key aspect. Terraform keeps track of the current state of your infrastructure. This state must be stored securely and consistently, especially in team environments.
You also need to think about environment separation. Development, staging, and production should be isolated but defined using similar configurations.
Finally, observability should be integrated from the start. While Terraform provisions infrastructure, you need monitoring and logging to understand how it behaves in production.

Why Terraform Scales with You

Terraform works well for small projects, but its real value becomes apparent as systems grow.
As you add more services, environments, and dependencies, manual management becomes unsustainable. Terraform provides a structured way to manage this complexity.
It enforces consistency. It enables automation. It creates a single source of truth for your infrastructure.
Most importantly, it allows teams to move faster without sacrificing reliability.
By defining infrastructure as code, you reduce ambiguity. You make systems easier to understand, easier to debug, and easier to evolve.
That is what takes you from zero to production in a way that actually scales.

Building AI Agents That Can Control Cloud Infrastructure

Manish Shivanandhan — Thu, 26 Mar 2026 05:36:48 +0000

Cloud infrastructure has become deeply programmable over the past decade.

Nearly every platform exposes APIs that allow developers to create applications, provision databases, configure networking, and retrieve metrics.

This shift enabled automation via Infrastructure as Code and CI/CD pipelines, allowing teams to manage systems through scripts rather than dashboards.

Now another layer of automation is emerging. AI agents are starting to participate directly in development workflows. These agents can read codebases, generate implementations, run terminal commands, and help debug systems. The next logical step is to allow them to interact with the infrastructure itself.

Instead of manually inspecting dashboards or remembering complex command-line syntax, developers can ask an AI agent to check system state, deploy services, or retrieve metrics. The agent performs these tasks by interacting with cloud APIs on behalf of the user.

This capability opens the door to a new type of workflow where infrastructure becomes conversational, programmable, and deeply integrated into development environments.

In this article, we will explore how AI agents can interact with cloud infrastructure through APIs, the challenges of exposing large APIs to AI systems, and how architectures like MCP make it possible for agents to discover and execute infrastructure operations safely.

We will also look at a practical example of connecting an AI agent to a cloud platform like Sevalla using the search-and-execute pattern.

AI Agents Are Becoming Part of the Development Environment

Modern developer tools increasingly embed AI assistants directly inside coding environments. Editors such as Cursor, Windsurf, and Claude Code allow developers to ask questions about their projects, generate new code, and execute commands without leaving the editor.

Instead of manually navigating documentation or writing boilerplate code, developers can simply describe what they want. The AI interprets the request and produces the necessary actions.

This approach is already common for tasks like writing functions, refactoring code, or debugging errors. However, infrastructure management is still largely handled through dashboards, terminal commands, or external tooling.

If AI agents are going to assist developers effectively, they need access to the same systems developers interact with every day. That means accessing APIs that manage applications, databases, deployments, and other infrastructure resources.

The challenge is providing that access in a structured and scalable way.

Connecting AI Agents to External Systems

AI agents do not inherently know how to interact with external services. They need a framework that allows them to call tools and access data safely.

Model Context Protocol, or MCP, provides one such framework. MCP is designed to let AI assistants connect to external tools in a standardized way.

An MCP server exposes tools that an AI agent can call when it needs information or wants to act. These tools might retrieve data from a database, query logs, interact with APIs, or execute commands on a remote system.

When the AI agent receives a request from the user, it determines which tool to call and executes that tool through the MCP server. The results are returned to the agent, which can then continue reasoning about the problem.

This architecture allows AI assistants to interact with complex systems while maintaining a clear boundary between the agent and the external environment.

The Challenge of Large Cloud APIs

While MCP enables connecting AI agents to infrastructure systems, cloud platforms introduce an additional challenge.

Most cloud platforms expose large APIs with many endpoints. A typical platform might include endpoints for managing applications, databases, storage, networking, domains, metrics, logs, and deployment pipelines.

If an MCP server exposes each endpoint as a separate tool, the number of tools can quickly grow into the hundreds.

This creates several problems. First, the AI agent must understand the purpose and parameters of every available tool before deciding which one to use. This increases the amount of context required for the agent to operate effectively.

Second, maintaining hundreds of tools becomes difficult for developers who build and maintain the MCP server.

Third, the system becomes rigid. Every time a new API endpoint is added, a new tool must also be created and documented.

For large APIs, this approach quickly becomes impractical.

A Simpler Pattern for API Access

A different architecture solves this problem by dramatically reducing the number of tools exposed to the AI.

Instead of providing a separate tool for every API endpoint, the MCP server exposes only two capabilities.

The first capability allows the agent to search the API specification. This lets the agent discover available endpoints, understand parameters, and inspect request or response schemas.

The second capability allows the agent to execute code that calls the API.

In this model, the AI agent dynamically generates the code required to call the API. Because the agent can search the specification and write its own API calls, the MCP server does not need to define individual tools for every endpoint.

This pattern drastically reduces the complexity of the integration while still giving the agent full access to the underlying platform.

Why Sandboxed Code Execution Is Important

Allowing AI agents to generate and execute code raises important security considerations.

If the generated code runs unrestricted, it could potentially access sensitive parts of the system or perform unintended operations. To prevent this, the execution environment must be carefully controlled.

A common solution is running the generated code inside a sandboxed environment. In this setup, the code runs in an isolated runtime with limited permissions. The environment exposes only specific functions that allow interaction with the platform’s API.

Because the code cannot access the host system directly, the risk of unintended behavior is greatly reduced. At the same time, the AI agent retains the flexibility to generate custom API calls as needed.

This combination of dynamic code generation and sandboxed execution makes it possible for AI agents to interact with complex APIs safely.

Practical Example with Sevalla

A practical implementation of this architecture can be seen in the Sevalla MCP server, which exposes a cloud platform’s API to AI agents through the search-and-execute pattern.

Sevalla is a PaaS provider designed for developers shipping production applications. It offers app hosting, database, object storage, and static site hosting for your projects. We also have other options, such as AWS and Azure, that come with their own MCP tools.

Instead of registering hundreds of tools for every API endpoint, the server provides only two tools that allow the AI agent to explore and interact with the entire platform. Find the full documentation for Sevalla’s MCP server here.

The first tool, search, allows the agent to query the platform’s OpenAPI specification. Through this interface the agent can discover available endpoints, understand parameters, and inspect response schemas.

Because the API specification is searchable, the agent does not need to know the structure of the platform’s API in advance. It can explore the API dynamically based on the task it needs to perform.

For example, if the user asks the agent to list all applications running in their account, the agent can begin by searching the API specification.

const endpoints = await sevalla.search("list all applications")

The result returns the relevant API definitions, including the correct path and parameters required for the request. Once the agent understands which endpoint to use, it can generate the necessary API call.

The second tool, execute, runs JavaScript inside a sandboxed V8 environment. Within this environment the agent can call the API using a helper function provided by the platform.

const apps = await sevalla.request({ method: "GET", path: "/applications" })
Because the code runs inside an isolated V8 sandbox, the generated script cannot access the host system. The only permitted interaction is through the API helper function. This ensures that the AI agent can perform infrastructure operations safely while still retaining the flexibility to generate dynamic API calls.

This approach allows an agent to discover and interact with many parts of the platform without requiring predefined tools for each capability. After discovering endpoints through the API specification, the agent can retrieve application data, inspect deployments, query metrics, or manage infrastructure resources through generated API calls.

The design also significantly reduces context usage. Traditional MCP integrations might require hundreds of tools to represent every endpoint of a large API. In contrast, the search-and-execute pattern allows the entire API surface to be accessed through just two tools.

For developers connecting AI assistants to infrastructure platforms, this architecture provides a practical way to expose large APIs while keeping the integration simple and efficient.

What This Means for Developers

Allowing AI agents to interact with infrastructure APIs changes how developers manage systems.

Instead of manually navigating dashboards or writing long sequences of commands, developers can describe what they want in natural language. The AI agent can interpret the request, discover the relevant API endpoints, and execute the required operations.

This approach also improves observability and debugging. When something goes wrong, the agent can query logs, inspect metrics, and retrieve system state without requiring the developer to manually gather information.

Over time, this type of integration could significantly reduce the friction involved in managing complex cloud systems.

The Next Evolution of Infrastructure Automation

Infrastructure automation has evolved through several stages. Early cloud systems relied heavily on manual configuration through web interfaces. Infrastructure as Code later allowed teams to define infrastructure using scripts and configuration files.

CI/CD pipelines then automated the process of deploying and updating systems.

AI agents represent the next step in this progression. By combining APIs, MCP integrations, and sandboxed execution environments, developers can allow intelligent systems to reason about infrastructure and interact with it safely.

Instead of static integrations, agents can dynamically discover and call APIs as needed. This makes infrastructure management more flexible and accessible while maintaining the reliability of programmable systems.

As AI tools become more deeply embedded in development environments, the ability for agents to understand and control infrastructure will likely become a standard capability for modern platforms.

Infrastructure as Code with APIs: Automating Cloud Resources the Developer Way

Manish Shivanandhan — Fri, 20 Mar 2026 04:09:01 +0000

Modern software development moves fast. Teams deploy code many times a day. New environments appear and disappear constantly. In this world, manual infrastructure setup simply does not scale.

For years, developers logged into dashboards, clicked through forms, and configured servers by hand. This worked for small projects, but it quickly became fragile. Every manual step increased the chance of mistakes. Environments drifted apart. Reproducing the same setup became difficult.

Infrastructure as Code (IaC) solves this problem. Instead of clicking through interfaces, developers define infrastructure using code. This approach makes infrastructure predictable, repeatable, and easy to automate.

In recent years, another approach has become popular alongside traditional IaC tools: using cloud APIs directly to create and manage infrastructure. This gives developers full control over how resources are provisioned and integrated into workflows.

This article explains what Infrastructure as Code means, why APIs are a powerful way to implement it, and how developers can automate cloud resources using simple scripts.

What Is Infrastructure as Code?

Infrastructure as Code means managing infrastructure using code instead of manual processes.

Instead of setting up servers, databases, and networks by hand, you define them in scripts or configuration files. These files describe the desired state of your infrastructure. A tool or script then creates and maintains that state automatically.

For example, instead of manually creating a database, you might define it in code like this:

database: name: app_db engine: postgres version: 16
Once the code runs, the database is created automatically.

This approach provides several key benefits.

First, it improves consistency. Every environment is created from the same definition. Development, staging, and production environments stay aligned.

Second, it improves repeatability. If infrastructure fails, it can be recreated from code in minutes.

Third, it improves version control. Infrastructure definitions live in the same repositories as application code. Teams can review, track, and roll back changes.

Finally, it enables automation. Infrastructure can be created during deployments, tests, or CI/CD pipelines.

The Limits of Manual Infrastructure

Before IaC became common, infrastructure management relied heavily on dashboards and manual configuration.

A developer would open a cloud console and perform steps like:

Create a server
Attach storage
Configure environment variables
Connect a database
Add a domain

These steps worked, but they introduced problems.

Manual configuration is hard to document. Even if teams write guides, small details are often missed. Over time, environments drift apart.

Manual processes also slow down development. Spinning up a new environment may take hours instead of seconds.

Even worse, manual infrastructure cannot easily be tested. If something breaks, reproducing the same conditions becomes difficult.

Infrastructure as Code removes these problems by turning infrastructure into something that can be scripted, tested, and automated.

Why APIs Are a Powerful IaC Tool

Many people associate Infrastructure as Code with tools like Terraform or CloudFormation. These tools are powerful, but they are not the only option.

Every modern cloud platform exposes an API. That API allows developers to create resources programmatically.

This means infrastructure can be controlled directly from code using HTTP requests or command-line interfaces.

Using APIs for IaC has several advantages.

First, it offers maximum flexibility. Developers can integrate infrastructure creation directly into applications, deployment scripts, or internal tools.

Second, it reduces tooling complexity. Instead of learning a specialized IaC language, teams can use languages they already know, such as Python, JavaScript, or Bash.

Third, it enables dynamic infrastructure. Scripts can create resources only when needed, scale them automatically, and remove them when work is complete.

For example, a test suite could automatically create a database, run tests, and delete the database afterwards. This keeps environments clean and reduces costs.

APIs essentially turn the cloud into a programmable platform.

Automating Infrastructure with Scripts

Using APIs for infrastructure automation usually follows a simple workflow.

First, a script authenticates with the cloud platform using an API token or credentials.

Second, the script sends requests to create or modify resources such as applications, databases, or storage.

Third, the script captures identifiers or configuration values from the response.

Finally, those values are used in later steps, such as deployments or integrations.

Because these steps run in code, they can easily be included in CI/CD pipelines.

A typical pipeline might do the following:

Create infrastructure
Deploy the application
Run tests
Collect metrics
Destroy temporary environments

This approach ensures every deployment follows the same process.

Practical example with Sevalla

A practical way to apply Infrastructure as Code through APIs is to use a command-line interface that directly interacts with a cloud platform’s API. This allows developers to automate infrastructure creation using scripts rather than dashboards.

One example is the Sevalla CLI, which exposes infrastructure operations as terminal commands that can be executed manually or inside automation pipelines.

Sevalla is a developer-centric PaaS designed to simplify your workflow. They provide high-performance application hosting, managed databases, object storage, and static sites in one unified platform. Alternate options include AWS and Azure, which require complex CLI tools and heavy DevOps overhead compared to Sevalla’s simplicity and ease of use.

You can install the CLI using the following shell command.

curl -fsSL https://raw.githubusercontent.com/sevalla-hosting/cli/main/install.sh)

Once installed, you can view the list of all available commands using the help command.

The first step is authentication. Make sure you have an account on Sevalla before using the CLI.

sevalla login

For automated environments such as CI/CD pipelines, authentication can be done with an API token. The token is stored in an environment variable so scripts can run without user interaction.

export SEVALLA_API_TOKEN="your-api-token"

Once authenticated, you can quickly view a list of your apps using sevalla apps list

Your infrastructure can now be created directly from the command line. For example, a developer might start by creating an application service that will run the backend code.

sevalla apps create --name myapp --source privateGit --cluster <id>

This command provisions a new application resource on the platform. Instead of navigating through a web interface and filling out forms, the entire setup is performed through a single command.

Because the command can be stored in scripts or configuration files, it becomes part of the project’s infrastructure definition.

After creating the application, developers often need a database. That can also be provisioned programmatically.

sevalla databases create \ --name mydb \ --type postgresql \ --db-version 16 \ --cluster <id> \ --resource-type <id> \ --db-name mydb \ --db-password secret

This creates a PostgreSQL database with a defined version and credentials. In an automated workflow, the database creation step could run during environment setup for staging or testing.

Once the application and database exist, the next step might be configuring environment variables so the application can connect to the database.

sevalla apps env-vars create <app-id> --key DATABASE_URL --value "postgres://..."
These configuration values can be injected during deployments, ensuring the application always receives the correct settings.

Deployment automation is another key part of Infrastructure as Code. Instead of manually triggering deployments, a script can deploy new code whenever a repository is updated.

sevalla apps deployments trigger --branch main
This allows CI/CD systems to deploy new versions of the application automatically after tests pass.

Infrastructure automation also includes scaling and monitoring. For example, if an application needs more instances to handle traffic, the number of running processes can be updated programmatically.

sevalla apps processes update <process-id> --app-id <app-id> --instances 3
Metrics can also be retrieved through the CLI. This allows monitoring tools or scripts to analyze system performance.

sevalla apps processes metrics cpu-usage <app-id> <process-id>
Similarly, application metrics such as response time or request rates can be queried to detect performance issues.

Another common step in infrastructure automation is configuring domains. Instead of manually linking domains to applications, a script can add them during environment setup.

sevalla apps domains add <app-id> --name example.com
With these commands combined in scripts or pipelines, developers can fully automate the lifecycle of their infrastructure. A CI pipeline could create an application, provision a database, configure environment variables, deploy code, attach a domain, and monitor performance — all without human intervention.

Because every command supports JSON output, scripts can also capture values returned by the platform and reuse them in later steps. For example:

APP_ID=$(sevalla apps list --json | jq -r '.[0].id')
This ability to chain commands together makes it easy to build powerful automation workflows.

In practice, teams often place these commands inside deployment scripts or pipeline steps. Whenever code is pushed to a repository, the pipeline automatically provisions or updates the infrastructure needed to run the application.

This approach demonstrates how APIs and automation tools can turn infrastructure into something developers manage the same way they manage application code, through scripts, version control, and automated workflows.

Infrastructure as Code Improves Developer Productivity

One of the biggest benefits of Infrastructure as Code is developer productivity.

Developers no longer need to wait for infrastructure changes or manually configure environments.

Instead, infrastructure becomes part of the development workflow.

When a new feature requires a service, the developer simply adds the infrastructure definition to the repository. The pipeline then creates it automatically.

This reduces delays and keeps development moving quickly.

It also makes onboarding easier. New team members can spin up a full environment with a single command.

The Future of Infrastructure
Cloud infrastructure continues to evolve toward automation and programmability.

Platforms increasingly expose APIs that allow every resource to be created, configured, and monitored through code.

This trend aligns naturally with the way developers already work.

Applications are built with code. Deployments are automated with code. It makes sense that infrastructure should also be defined with code.

Infrastructure as Code with APIs takes this idea even further. It allows infrastructure to be embedded directly into development workflows, pipelines, and internal tools.

The result is faster development, fewer configuration errors, and more reliable systems.

Conclusion

Infrastructure as Code has transformed how teams manage cloud environments.

By replacing manual configuration with code, organizations gain consistency, automation, and repeatability.

Using APIs to control infrastructure adds another level of flexibility. Developers can integrate infrastructure directly into scripts, pipelines, and applications.

This approach turns the cloud into a programmable platform.

As systems grow more complex and deployment cycles accelerate, the ability to automate infrastructure will only become more important.

For modern development teams, treating infrastructure as code is no longer optional. It is the foundation of reliable and scalable software delivery.

How to Deploy Your Own Agent using OpenClaw

Manish Shivanandhan — Mon, 09 Mar 2026 04:27:19 +0000

OpenClaw lets you run a powerful AI assistant on your own infrastructure, and this guide walks you through deploying it reliably from setup to production.

OpenClaw is a self-hosted AI assistant designed to run under your control instead of inside a hosted SaaS platform.

It can connect to messaging interfaces, local tools, and model providers while keeping execution and data closer to your own infrastructure.

The project is actively developed, and the current ecosystem revolves around a CLI-driven setup flow, onboarding wizard, and multiple deployment paths ranging from local installs to containerised or cloud-hosted setups.

This article explains how to deploy your own instance of OpenClaw from a practical systems perspective. We will look at how to deploy it on your local machine as well as a PaaS provider like Sevalla.

The goal is not just to “make it run,” but to understand deployment choices, architecture implications, and operational tradeoffs so you can run a stable instance long term.

Note: It is dangerous to give an AI system full control of your system. Make sure you understand the risks before running it on your machine.

Understanding What You Are Deploying

Before touching installation commands, it helps to understand the runtime model.

OpenClaw is essentially a local-first AI assistant that runs as a service and exposes interaction through chat interfaces and a gateway architecture.

The gateway acts as the operational core, handling communication between messaging platforms, models, and local capabilities.

In practical terms, deploying OpenClaw means deploying three layers.

The first layer is the CLI and runtime, which launches and manages the assistant.

The second layer is configuration and onboarding, where you select model providers and integrations.

The third layer is persistence and execution context, which determines whether OpenClaw runs on your laptop, a VPS, or inside a container.

Because OpenClaw runs with access to local resources, deployment decisions are not only about convenience but also about security boundaries. Treat it as an administrative system, not just a chatbot.

Deploying on a Local Machine

OpenClaw supports multiple deployment approaches, and the right one depends on your goals.

The simplest route is to install it directly on a local machine. This is ideal for experimentation, private workflows, or development because onboarding is fast and maintenance is minimal.

The installer script handles environment detection, dependency setup, and launching the onboarding wizard.

The fastest way to install OpenClaw is via the official installer script. The installer downloads the CLI, installs it globally through npm, and launches onboarding automatically.

curl -fsSL https://openclaw.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

This method abstracts away most environmental complexity and is recommended for first-time deployments.

If you already maintain a Node environment, you can install it directly using npm.

npm i -g openclaw

The CLI is then used to run onboarding and optionally install a daemon for persistent background execution. This approach gives you more control over versioning and update cadence.

openclaw onboard

Regardless of installation path, verify that the CLI is discoverable in your shell. Environment path issues are common when global npm packages are installed under custom Node managers.

The Onboarding Process

Once installed, OpenClaw relies heavily on onboarding to bootstrap configuration.

During onboarding you will select an AI provider, configure authentication, and choose how you want to interact with the assistant. This process establishes the core runtime state and generates local configuration files used by the gateway.

Onboarding also allows you to connect messaging channels such as Telegram or Discord. These integrations transform OpenClaw from a local CLI tool into an always-accessible assistant.

From a deployment perspective, this is the moment where availability requirements change. If you connect external chat platforms, your instance must remain online consistently.

You can skip certain onboarding steps and configure integrations later, but for production deployments it is better to complete the initial configuration so you can validate end-to-end functionality immediately.

Once you add an OpenAI API key or Claude key, you can choose to open the web UI.

Go to localhost:18789 to interact with OpenClaw.

Deploying on the Cloud using Sevalla

A second approach is to deploy to a VPS or cloud instance. This model gives you always-on availability and makes it possible to interact with OpenClaw from anywhere.

A third approach is containerised deployment using Docker or similar tooling. This provides reproducibility and cleaner dependency isolation.

Docker setups are particularly useful if you want predictable upgrades or easy migration between machines. OpenClaw’s repository includes scripts and compose configurations that support container execution workflows.

I have set up a custom Docker image to load OpenClaw into a PaaS platform like Sevalla.

Sevalla is a developer-friendly PaaS provider. It offers application hosting, database, object storage, and static site hosting for your projects.

Log in to Sevalla and click “Create application”. Choose “Docker image” as the application source instead of a GitHub repository. Use manishmshiva/openclaw as the Docker image, and it will be pulled automatically from DockerHub.

Click “Create application” and go to the environment variables. Add an environment variable ANTHROPIC_API_KEY. Then go to “Deployments” and click “Deploy now”.

Once the deployment is successful, you can click “Visit app” and interact with the UI with the sevalla provided url.

Interacting with the Agent

There are many ways to interact with the agent once you set up Openclaw. You can configure a Telegram bot to interact with your agent. Basically, the agent will (try to) do a task similar to a human assistant. Its capabilities depend on how much access you provide the agent.

You can ask it to clean your inbox, watch a website for new articles, and perform many other tasks. Please note that providing OpenClaw access to your critical apps or files is not ideal or secure. This is still a system in its early stages, and the risk of it making a mistake or exposing your private information is high.

Here are some of the ways people are using OpenClaw.

Security and Operational Considerations

Because OpenClaw can execute tasks and access system resources, deployment security is not optional. The safest baseline is to bind services to localhost and access them through secure tunnels when remote control is required. This significantly reduces exposure risk.

When deploying on a VPS, harden the host like any administrative service. Use non-root users, keep packages updated, restrict inbound ports, and monitor logs. If you are integrating messaging channels, treat tokens and API keys as sensitive secrets and avoid storing them in plaintext configuration where possible.

Containerization helps isolate dependencies but does not eliminate risk. The container still executes code on your host, so network and volume permissions should be carefully scoped.

Updating and Maintaining Your Instance

OpenClaw evolves quickly, with frequent releases and feature changes. Keeping your instance updated is important not only for features but also for stability and compatibility with integrations.

For npm-based installations, updates are straightforward, but you should test upgrades in a staging environment if your assistant handles important workflows. For source-based deployments, pull changes and rebuild consistently rather than mixing old build artifacts with new code.

Monitoring is another overlooked aspect. Even simple log inspection can reveal integration failures early. If your deployment is mission-critical, consider external uptime checks or process supervisors.

Conclusion

Deploying your own OpenClaw agent is ultimately about taking control of how your AI assistant works, where it runs, and how it fits into your daily workflows. While the setup process is straightforward, the real value comes from understanding the choices you make along the way, whether you run it locally for privacy, host it in the cloud for constant availability, or use containers for consistency and portability.

As the ecosystem around self-hosted AI continues to evolve, tools like OpenClaw make it possible to move beyond relying entirely on third-party platforms. Running your own agent gives you flexibility, ownership, and the freedom to shape the experience around your needs.

Start small, experiment safely, and gradually build confidence in how your assistant operates. Over time, what begins as a simple deployment can become a dependable, personalized system that works the way you want , under your control.

A Vibe Coder’s Guide to Deployment using a PaaS

Manish Shivanandhan — Wed, 04 Mar 2026 12:47:50 +0000

A practical, no-nonsense guide to getting your vibe-coded app live with a PaaS, without falling into DevOps rabbit holes.

Vibe coding is about momentum.

You open your editor, prompt an AI, stitch pieces together, and suddenly you have something that works.

Maybe it’s messy. Maybe the architecture is not perfect. But it’s alive, and that’s the point.

Then comes deployment. This is where the vibe usually dies.

Suddenly, you’re reading about containers, load balancers, CI/CD pipelines, infrastructure diagrams, and networking concepts you never asked for. You wanted to ship a thing. Instead, you’re learning accidental DevOps.

The truth is simple. Most vibe-coded apps don’t need complex infrastructure. They just need a clean path from code → live URL.

That’s where a Platform-as-a-Service fits in. It removes the infrastructure ceremony and lets deployment feel like a natural extension of building.

This guide is not about perfect production architecture. It’s about shipping fast without losing momentum.

In this article, we will look at how to deploy a simple vibe-coded app using Sevalla. There are other options like Railway, render, etc., with similar features, and you can pick one from this list.

What “Vibe Deployment” Actually Means

Traditional deployment advice assumes you’re building a long-term, heavily engineered system.

Vibe coders operate differently. The goal is speed, feedback, and iteration.

A vibe-friendly deployment workflow has a few core characteristics:

Minimal configuration: You shouldn’t spend hours setting up environments before seeing your app live.
Fast feedback loops: Every push should quickly show you the result.
Safe defaults: You shouldn’t need deep infra knowledge to avoid obvious mistakes.

In other words, deployment shouldn’t be a “phase.” It should be part of the normal development loop.

You build. You push. It updates. You keep going.

The Typical Vibe-Coded App

Most vibe-coded projects look similar under the hood.

There’s usually a frontend generated or accelerated by AI using React, Next.js, Vue, or something equally modern. The backend might be a small API, sometimes written quickly without strict structure.

Data lives in a managed database. Authentication might be glued together from a few libraries.

The code evolves rapidly. Patterns change weekly. Files get renamed, rewritten, or deleted without ceremony.

And that’s fine.

The problem is that traditional deployment workflows assume stability and planning. They expect clean separation between environments, carefully defined build pipelines, and long-term operational thinking.

Vibe-coded apps need the opposite: something that tolerates change and rewards experimentation.

The PaaS Mental Model

The biggest shift with a PaaS is how you think about deployment.

Instead of asking:

Which server should I use?
How do I configure networking?
What container setup do I need?

You think in terms of:

Connect your repository.
Configure the app once.
Deploy automatically.

A PaaS treats your project as a service that can be built and run. You don’t manage infrastructure; you define the minimum information needed to run your code.

There are only a few concepts you really need to understand:

Services: Each deployable unit of your app. A frontend or backend typically becomes a service.
Environment variables: Secrets and configuration that differ between local and production.
Auto builds: Every code push triggers a build and deployment.

That’s it. The system handles the rest.

The result is important: deployment stops being a separate discipline and becomes just another part of coding.

Shipping Your First App on Sevalla

Sevalla is a developer-friendly PaaS provider. It offers application hosting, database, object storage, and static site hosting for your projects.

Let’s walk through what deployment actually looks like in practice. I have already written a few tutorials on both Python and Node.js projects, building an app from scratch and deploying it on Sevalla.

Step 1: Connect Your Repository

The starting point is your Git repository. Log in to Sevalla using your GitHub account, or you can connect it after logging in with your email.

You connect your project to Sevalla and select the branch you want to deploy. This creates a direct link between your code and the live app.

You can also enalbed “Automatic deployments”. Once you create an app, deployment becomes automatic. You push code, and Sevalla takes care of building and publishing.

No manual uploads. No SSH sessions. No server setup.

Step 2: Configure the Runtime

Next, you define how your app runs.

Most modern frameworks are detected automatically. If you’ve built something common, you usually won’t need to tweak much.

This is where you add environment variables. API keys, database URLs, authentication secrets, and anything that shouldn’t live inside your codebase.

A simple rule for vibe coders: If it changes between local and production, make it an environment variable.

Once set, you rarely need to touch this again.

Step 3: Deploy

Now you deploy.

Sevalla builds the application, installs dependencies, and launches it. After a short wait, you get a live URL.

This is the moment that matters. Your app is no longer a local experiment; it’s something real people can use.

And importantly, you didn’t need to make infrastructure decisions to get there.

Step 4: Iterate Like a Vibe Coder

Now your workflow shines!

You make a change locally. Commit. Push.

Sevalla rebuilds and redeploys automatically.

Your deployment process becomes invisible, just part of your normal coding rhythm.

This matters more than most people realise. When deployment is effortless, you ship more often. When you ship more often, you learn faster.

And fast learning is the real advantage of vibe coding.

Things Vibe Coders Usually Break (and How PaaS Helps)

Even simple deployment workflows can go wrong. Some patterns show up repeatedly.

Missing environment variables: The app works locally but crashes in production. A PaaS surfaces configuration clearly, making it easier to spot.
Localhost assumptions: Hardcoded URLs or local file paths break once deployed. Using environment configuration fixes this early.
File storage confusion: Local files disappear between deployments. Treat storage as external from day one.
Ignoring logs: Many developers only look at logs after panic sets in. Sevalla’s centralised logs make debugging faster when something inevitably fails.

The important point: these aren’t advanced problems. They’re beginner deployment mistakes, and the platform’s defaults help you avoid most of them.

The Minimal Production Checklist

Before you call something “live,” run through a quick checklist:

Environment variables are set correctly.
Database is external, not local.
Logs are enabled and readable.
Custom domain is connected if needed.
You know how to roll back to a previous version.

That’s enough for most early-stage projects.

You don’t need complex monitoring stacks or multi-region infrastructure to start learning from real users.

Why This Workflow Works for Vibe Builders

Indie builders and vibe coders succeed by maintaining velocity. The highest hidden cost in software isn’t infrastructure, it’s context switching.

Every time you stop building to become a part-time DevOps engineer, momentum drops.

A PaaS system’s biggest advantage isn’t technical sophistication. It’s psychological. You stay in the builder mindset.

You focus on product decisions instead of infrastructure decisions.

And because deployment feels safe, you ship more frequently. Small releases reduce risk, reduce anxiety, and make experimentation normal.

This is exactly the environment where small projects grow into real products.

Conclusion

The best deployment system is one you barely think about.

For vibe coders, deployment shouldn’t be a scary milestone or a weekend project. It should feel like pressing save, just another step in the creative loop.

Build something. Push it live. Learn from users. Repeat.

That’s the real goal.

And when deployment stops being a bottleneck, the vibe stays alive.

Top 5 Heroku Alternatives for Deployment in 2026

Manish Shivanandhan — Thu, 12 Feb 2026 04:46:32 +0000

For more than a decade, Heroku defined what “developer-friendly deployment” meant. Push code, forget servers, and focus on shipping features.

That promise shaped an entire generation of platform-as-a-service products. In 2026, that landscape is changing.

Heroku has clearly stated that it is moving into a sustaining engineering model. The platform remains stable, secure, and supported, but active innovation is no longer the focus.

For many teams, this is acceptable. For others, especially startups and product teams planning three to five years ahead, it raises an important question: where should new applications live?

In this article, we will look at five strong Heroku alternatives that are well-positioned for 2026. Each platform approaches deployment differently, but all aim to preserve what developers loved about Heroku while improving on cost, flexibility, or modern workflows.

What we will Cover

Why Teams Are Looking Beyond Heroku
Sevalla: The Closest Successor to Classic Heroku
Render: A Broad Platform for Growing Teams
Fly.io: Global-First Deployment for Latency-Sensitive Apps
Upsun: Enterprise-Grade Control Without Losing Structure
Vercel: The Frontend-Native Deployment Platform
Choosing the Right Heroku Alternative in 2026
Conclusion

Why Teams Are Looking Beyond Heroku

Heroku’s shift toward maintenance over expansion signals maturity, not failure. However, modern teams expect faster iteration, deeper infrastructure control, and tighter integration with cloud-native tooling.

AI workloads, edge computing, and global latency expectations are also reshaping deployment needs.

As a result, teams want platforms that feel simple on day one but do not become limiting as scale and complexity grow.

The alternatives discussed here are not identical replacements. Each represents a different philosophy about how applications should be built and operated in 2026.

Sevalla: The Closest Successor to Classic Heroku

Sevalla has quietly positioned itself as one of the most Heroku-like platforms available today. The core idea is familiar. You deploy applications without managing servers, environments are predictable, and the platform stays out of your way.

What makes Sevalla compelling in 2026 is its balance between simplicity and control. It keeps the developer experience tight while avoiding the opaque pricing and rigid abstractions that frustrated many Heroku users over time. Deployments are fast, logs are easy to access, and scaling feels intuitive rather than magical.

Sevalla is particularly attractive for mid-sized teams and also for enterprises that want a clean path from prototype to production. It supports modern application stacks without forcing you into complex infrastructure decisions too early. For teams migrating directly from Heroku, Sevalla often feels like the least disruptive transition.

The platform’s biggest strength is restraint. It does not try to be everything at once. Instead, it focuses on being a reliable home for long-running services, APIs, and background workers. In 2026, that clarity is refreshing.

Built for the enterprise, Sevalla meets the highest standards of security. They are fully compliant with SOC2, ISO 27017, and ISO 27001:2022, ensuring your data stays protected and your requirements are met.

Render: A Broad Platform for Growing Teams

Render takes a more expansive approach. While it is often compared to Heroku, Render aims to cover a wider range of use cases, from simple web services to complex microservice architectures.

Render stands out because it blends platform simplicity with infrastructure transparency. You still get managed databases, background jobs, and zero-downtime deploys, but you also gain more visibility into how resources are allocated. This makes it easier to reason about cost and performance as systems grow.

For teams that expect to scale steadily, Render offers a comfortable middle ground. It removes much of the operational burden while allowing deeper configuration when needed. Many engineering teams appreciate that Render feels less restrictive than Heroku without pushing them into full DevOps territory.

In 2026, Render is especially popular with SaaS companies that have outgrown entry-level platforms but are not ready to manage Kubernetes clusters themselves. It supports modern CI/CD workflows and integrates well with common developer tools.

Fly.io: Global-First Deployment for Latency-Sensitive Apps

Fly.io represents a different philosophy entirely. Instead of abstracting infrastructure away, Fly.io embraces it, but makes it programmable and developer-friendly.

Fly.io allows applications to run close to users by deploying workloads across multiple regions by default. This makes it ideal for applications where latency matters, such as real-time collaboration tools, gaming backends, or global APIs.

Unlike Heroku, Fly.io expects developers to understand a bit more about how their application runs. You interact with virtual machines rather than dynos, and configuration is more explicit. However, this added complexity comes with real power.

In 2026, Fly.io appeals strongly to experienced teams that want performance and control without adopting heavy orchestration systems. It is not always the easiest option, but it is one of the most flexible. For teams willing to invest in understanding the platform, Fly.io can outperform traditional PaaS solutions in both speed and cost efficiency.

Upsun: Enterprise-Grade Control Without Losing Structure

Upsun, previously known as Platform.sh, brings a more opinionated, enterprise-oriented model to application deployment. It is designed for teams that care deeply about environment parity, reproducibility, and long-term maintainability.

Upsun treats infrastructure as part of the application. Environments are versioned alongside code, and deployments are deterministic. This approach reduces surprises and makes complex systems easier to reason about over time.

For organizations with compliance requirements or multi-environment workflows, Upsun offers a level of rigor that Heroku never aimed to provide. At the same time, it abstracts away much of the operational burden that typically comes with such control.

In 2026, Upsun is particularly well-suited for regulated industries, large content platforms, and teams with multiple long-lived environments. It is less about rapid experimentation and more about predictable, repeatable delivery at scale.

Vercel: The Frontend-Native Deployment Platform

Vercel is often discussed in a different category, but it deserves inclusion in any modern deployment conversation. Vercel is optimized for frontend applications, serverless functions, and edge workloads.

If Heroku excelled at hosting monolithic web apps, Vercel excels at composable, frontend-driven architectures. It integrates deeply with modern frameworks and makes global deployment nearly effortless.

In 2026, many applications are frontend-heavy, with APIs split into smaller services or serverless functions. For these use cases, Vercel offers a developer experience that feels faster and more modern than traditional PaaS platforms.

However, Vercel is not a full replacement for Heroku in every scenario. Long-running background jobs and stateful services often live elsewhere. Still, for teams building modern web products, Vercel frequently becomes the centerpiece of their deployment strategy.

Choosing the Right Heroku Alternative in 2026

There is no single “best” Heroku replacement. The right choice depends on how your application behaves, how your team works, and how much control you want over infrastructure.

Sevalla is ideal for teams that want familiarity and minimal friction. Render suits growing teams that need flexibility without chaos. Fly.io is powerful for global, performance-sensitive systems. Upsun excels in structured, enterprise environments. Vercel dominates frontend-centric architectures.

The common thread is that deployment in 2026 is no longer one-size-fits-all. Heroku set the standard, but the ecosystem has evolved. Today’s platforms offer sharper trade-offs, clearer philosophies, and better alignment with modern development patterns.

For teams starting new projects, the opportunity is clear. You can choose a platform that matches your future, not just your present.

Conclusion

Heroku is not disappearing, and for many existing workloads, it will continue to run reliably for years. However, its shift toward a sustaining engineering model makes one thing clear: teams building new products in 2026 should think carefully about where they place their long-term bets.

Deployment platforms are no longer just hosting choices. They shape how fast teams move, how systems scale, and how painful future migrations become.

In 2026, the strongest deployment strategy is intentional, not inherited. Heroku showed the industry what was possible. Its successors are now defining what comes next.

Hope you enjoyed this article. Learn more about me by visiting my website.

How to Build Your First AI Agent Deploy it to Sevalla

Manish Shivanandhan — Wed, 07 Jan 2026 11:02:56 +0000

Artificial intelligence is changing how we build software.

Just a few years ago, writing code that could talk, decide, or use external data felt hard.

Today, thanks to new tools, developers can build smart agents that read messages, reason about them, and call functions on their own.

One such platform that makes this easy is LangChain. With LangChain, you can link language models, tools, and apps together. You can also wrap your agent inside a FastAPI server, then push it to a cloud platform for deployment.

This article will walk you through building your first AI agent. You will learn what LangChain is, how to build an agent, how to serve it through FastAPI, and how to deploy it on Sevalla.

What is LangChain

LangChain is a framework for working with large language models. It helps you build apps that think, reason, and act.

A model on its own only gives text replies, but LangChain lets it do more. It lets a model call functions, use tools, connect with databases, and follow workflows.

Think of LangChain as a bridge. On one side is the language model. On the other side are your tools, data sources, and business logic. LangChain tells the model what tools exist, when to use them, and how to reply. This makes it ideal for building agents that answer questions, automate tasks, or handle complex flows.

Many developers use LangChain because it is flexible. It supports many AI models. It fits well with Python.

Langchain also makes it easier to move from prototype to production. Once you learn how to create an agent, you can reuse the pattern for more advanced use cases.

I have recently published a detailed langchain tutorial here.

Building Your First Agent with LangChain

Let us make our first agent. It will respond to user questions and call a tool when needed.

We will give it a simple weather tool, then ask it about the weather in a city. Before this, create a file called .env and add your openai api key. Langchain will automatically use it when making requests to Openai.

OPENAI_API_KEY=

Here is the code for our agent:

from langchain.agents import create_agent
from dotenv import load_dotenv

# load environment variables
load_dotenv()

# defining the tool that LLM can call
def get_weather(city: str) -> str:
 """Get weather for a given city."""
 return f"It's always sunny in {city}!"

# Creating an agent
agent = create_agent(model="gpt-4o",tools=[get_weather],   system_prompt="You are a helpful assistant")

result = agent.invoke({"messages":[{"role":"user","content":"What is the weather in san francisco?"}]})

This small program shows the power of LangChain agents.

First, we importcreate_agent, which helps us build the agent. Then we write a function called get_weather. It takes a city name and returns a friendly sentence.

The function acts as our tool. A tool is something the agent can use. In real projects, tools might fetch prices, store notes, or call APIs.

Next, we call create_agent. We give it three things. We pass the model we want to use. We list the tools we want it to call. And we give a system prompt. The system prompt tells the agent who it is and how it should behave.

Finally, we run the agent. We call invoke with a message.

The user asks for the weather in San Francisco. The agent reads this message. It sees that the question needs the weather function. So it calls our tool get_weather, passes the city, and returns an answer.

Even though this example is tiny, it captures the main idea. The agent reads natural language, figures out what tool to use, and sends a reply.

Later, you can add more tools or replace the weather function with one that connects to a real API. But this is enough for us to wrap and deploy.

Wrapping Your Agent with FastAPI

The next step is to serve our agent. FastAPI helps us expose our agent through an HTTP endpoint. That way, users and systems can call it through a URL, send messages, and get replies.

To begin, you install FastAPI and write a simple file like main.py. Inside it, you import FastAPI, load the agent, and write a route.

When someone posts a question, the api forwards it to the agent and returns the answer. The flow is simple.

The user talks to FastAPI. FastAPI talks to your agent. The agent thinks and replies.

Here is the FAST api wrapper for your agent.

from fastapi import FastAPI
from pydantic import BaseModel
import uvicorn
from langchain.agents import create_agent
from dotenv import load_dotenv
import os

load_dotenv()

# defining the tool that LLM can call
def get_weather(city: str) -> str:
    """Get weather for a given city."""
    return f"It's always sunny in {city}!"

# Creating an agent
agent = create_agent(
    model="gpt-4o",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

app = FastAPI()

class ChatRequest(BaseModel):
    message: str

@app.get("/")
def root():
    return {"message": "Welcome to your first agent"}

@app.post("/chat")
def chat(request: ChatRequest):
    result = agent.invoke({"messages":[{"role":"user","content":request.message}]})
    return {"reply": result["messages"][-1].content}

def main():
    port = int(os.getenv("PORT", 8000))
    uvicorn.run(app, host="0.0.0.0", port=port)

if __name__ == "__main__":
    main()

Here, FastAPI defines a /chat endpoint. When someone sends a message, the server calls our agent. The agent processes it as before. Then FastAPI returns a clean JSON reply. The API layer hides the complexity inside a simple interface.

At this point, you have a working agent server. You can run it on your machine, call it with Postman or cURL, and check responses. When this works, you are ready to deploy.

Deployment to Sevalla

You can choose any cloud provider, like AWS, DigitalOcean, or others to host your agent. I will be using Sevalla for this example.

Sevalla is a developer-friendly PaaS provider. It offers application hosting, database, object storage, and static site hosting for your projects.

Every platform will charge you for creating a cloud resource. Sevalla comes with a $50 credit for us to use, so we won’t incur any costs for this example.

Let’s push this project to GitHub so that we can connect our repository to Sevalla. We can also enable auto-deployments so that any new change to the repository is automatically deployed.

You can also fork my repository from here.

Log in to Sevalla and click on Applications -> Create new application. You can see the option to link your GitHub repository to create a new application.

Use the default settings. Click “Create application”. Now we have to add our openai api key to the environment variables. Click on the “Environment variables” section once the application is created, and save the OPENAI_API_KEY value as an environment variable.

Now we are ready to deploy our application. Click on “Deployments” and click “Deploy now”. It will take 2–3 minutes for the deployment to complete.

Once done, click on “Visit app”. You will see the application served via a url ending with sevalla.app . This is your new root url. You can replace localhost:8000 with this url and test in Postman.

Congrats! Your first AI agent with tool calling is now live. You can extend this by adding more tools and other capabilities, and push your code to GitHub, and Sevalla will automatically deploy your application to production.

Conclusion

Building AI agents is no longer a task for experts. With LangChain, you can write a few lines and create reasoning tools that respond to users and call functions on their own.

By wrapping the agent with FastAPI, you give it a doorway that apps and users can access. Finally, Sevalla makes it easy to push your agent live, monitor it, and run it in production.

This journey from agent idea to deployed service shows what modern AI development looks like. You start small. You explore tools. You wrap them and deploy them.

Then you iterate, add more capability, improve logic, and plug in real tools. Before long, you have a smart, living agent online. That is the power of this new wave of technology.

How to Build AI Workflows Without Code Using Activepieces and Sevalla

Manish Shivanandhan — Thu, 04 Dec 2025 11:31:44 +0000

Let’s learn how to use Activepieces to build smart AI workflows with a simple visual builder. No coding or complex setup needed.

Artificial intelligence is now part of daily work for many teams. People use it to write content, analyse data, answer support requests, and guide business decisions.

But building AI workflows is still hard for many users. Most tools need code, a complex setup, or long training.

Activepieces makes this much easier. It's an open source tool that lets anyone create smart workflows with a simple visual builder.

You can mix AI models, data sources, and systems without writing code. This makes automation more open to teams that want to work faster and cut manual effort.

In this guide, we will learn what ActivePieces is, how to work with it and how to deploy our own version to the cloud using Sevalla.

What is ActivePieces?

Activepieces is an open-source automation platform that focuses on ease of use.

You can host it on your own server or use it in the cloud. The platform uses a clean flow builder where each block represents a step. These blocks are called pieces.

A piece may call an API, connect to a tool like Google Sheets, run an AI model, or wait for human input. By linking pieces together, you can build workflows that act like agents.

They can listen to events, run analysis, create content, evaluate data, or push results into other tools.

Understanding the Activepieces ecosystem

The main goal of Activepieces is to let both technical and non-technical users build workflows that include AI. It gives a simple visual interface but also has a strong developer layer under the hood.

Developers can build new pieces in TypeScript. These custom pieces then appear in the visual builder for anyone to use. This keeps advanced logic invisible behind a friendly interface.

The platform has a growing library of over two hundred pieces. Many come from the community.

They include common tools like email, Slack, Google Workspace, OpenAI, and Notion. There are also pieces for reading links, parsing text, calling webhooks, or waiting for timed events.

The library grows fast because anyone can contribute new pieces. Each piece is an npm package, so it fits well into the wider JavaScript ecosystem.

Activepieces also supports human input. For example, a workflow can pause and wait for someone to review a message before sending it. It can also collect answers from a form.

These options make it possible to build flows that mix automation with human judgment. This is useful in tasks where risk or correctness matters, such as compliance checks or approval flows.

A major part of the platform is its AI-first design. It includes native support for popular AI providers. You can build agents that analyse text, rewrite messages, classify content, extract fields, or make decisions.

You can even ask the AI to clean data inside a flow, without needing code. This makes it easy to use AI to speed up work and remove repetitive steps.

Building a workflow in Activepieces

Every workflow begins with a trigger. A trigger is an action that starts the flow.

It may be a new message, a new file, a web request, or a timed schedule. After the trigger fires, the flow runs step by step. Each step is a piece you choose from the library.

The builder shows the flow in a simple vertical layout. You can add branches, loops, retries, and data mapping.

Data mapping is the process of telling the flow how to pass information from one step to another. It uses a simple interface where you pick fields from earlier steps and connect them to new ones.

When AI pieces are added, the workflow becomes more powerful. For example, you can pass text from a form to an AI model and get a summary.

You can pass a document link and extract the main points. You can ask the AI to answer a question or decide if a message fits a category. These results then move to the next step, where they can be stored or sent.

Deploying ActivePieces on the Cloud using Sevalla

To use Activepieces, you can either install it on your computer (not recommended due to the complex setup), buy a cloud subscription or self-host it.

If you prefer to install it on your computer, here are the instructions.

Self-hosting gives you full control and is usually preferred by technical teams who want to keep sensitive data in-house.

You can choose any cloud provider, like AWS, DigitalOcean, or others to set up ActivePieces. But I will be using Sevalla.

Sevalla is a PaaS provider designed for developers and dev teams shipping features and updates constantly in the most efficient way. It offers application hosting, database, object storage, and static site hosting for your projects.

I am using Sevalla for two reasons:

Every platform will charge you for creating a cloud resource. Sevalla comes with a $50 credit for us to use, so we won’t incur any costs for this example.
Sevalla has a template for ActivePieces, so it simplifies the manual installation and setup for each resource you will need for installation.

Click on the “ActivePieces” template. You will see the resources needed to provision the application. Click on “Deploy Template”.

You can see the resource being provisioned. Once the deployment is complete, go to the ActivePieces application and click on “Visit app”. Enter your name, email and password, and you will be taken to the dashboard.

Click on “New Flow”. You can either create a flow from scratch, or choose one of the many templates ActivePieces offers.

Let's pick the “LinkedIn content idea generator” template.

Click on “Use template”. You will see the workflow generated for you. You can also add/remove components based on your requirements.

You will see the option to update each block of the workflow. You can create connections to your email, Google Sheets, etc., to integrate them into the blocks.

In the rank news block, it will ask you to choose a model and add your api key. For example, you can find your OpenAI api key here. You will also see a pre-built prompt template ready for you to use with your workflow.

Great! You now have a production-grade ActivePieces server running on the cloud. You can use this to set up all your workflows.

Real-world examples

A sales team can automate lead enrichment by passing new leads through an AI model. The AI extracts company size, industry, and intent. The results go to a CRM. The team saves hours of manual research.

A content team can create a writing assistant. It gathers ideas from a form, generates outlines using an AI model, and stores drafts in Google Docs. Editors then refine the text.

A compliance team can process long documents. They upload a file, an AI model extracts key rules, and the workflow sends a summary to reviewers. This makes it easier to track changes in regulations.

An operations team can watch for new tickets in a helpdesk system. AI summarises the ticket. The workflow checks severity and sends it to the right team. This speeds up response times.

Conclusion

The idea behind Activepieces is simple. Automate work that slows you down. Mix AI with your tools. Build flows visually. Let both technical and non-technical users create automation. This helps teams move faster, reduce errors, and stay focused on meaningful work.

The rise of AI means teams will use more specialised models. They will also need smooth ways to link these models with their daily tools.

No-code platforms like Activepieces give teams control and speed without asking them to learn programming. The platform keeps improving with new pieces and stronger AI features. As the community grows, the number of available integrations will rise.

Hope you enjoyed this article. Find me on Linkedin or visit my website.

How to Build an AI-Driven Search Experience with Meilisearch and Sevalla

Manish Shivanandhan — Mon, 01 Dec 2025 15:21:32 +0000

Learn how AI-powered search with Meilisearch delivers fast, intuitive, and highly relevant results.

Search is one of the most important features in modern applications.

Users expect instant answers, useful suggestions, and results that match their intent even when they make spelling mistakes.

Most traditional search systems struggle to deliver this experience without complex and heavy infrastructure.

Meilisearch is an open-source search engine that changes this by offering a fast and developer-friendly engine that is easy to set up and extend.

When you combine Meilisearch with AI models for natural language understanding and semantic relevance, you can build a powerful and intuitive search experience that feels modern and intelligent.

This article explains how Meilisearch works, how to set it up, and how to integrate AI models to deliver better relevance and better ranking. You will also see how hybrid search and semantic embeddings work, and how to deploy Melisearch to the cloud using Sevalla.

Understanding Meilisearch

Meilisearch is a lightning-fast search engine that fits easily into any application.

It is built in Rust and designed to deliver results in less than fifty milliseconds. It supports semantic search, hybrid search, typo tolerance, sorting, geosearch, and extensive language support.

Melisearch also provides a clean RESTful API and a wide range of SDKs that make integration easy with JavaScript, Python, Go, PHP, Ruby, Rust and many other languages.

You can try Meilisearch by exploring the official demos. These demos show how Meilisearch is not limited to one specific use case but can fit many types of workflows.

Meilisearch supports two editions. The Community Edition is fully open source under the MIT license and can be used freely even for commercial products.

The Enterprise Edition introduces features like sharding and is governed by a commercial license. You can deploy Meilisearch yourself or choose Meilisearch Cloud, which handles hosting, updates, monitoring and analytics without requiring server maintenance.

Setting Up Meilisearch

Starting Meilisearch is simple. You can download the binary and run it directly or you can start it through Docker. Running through Docker is the fastest way to test it on your machine.

docker run -it --rm -p 7700:7700 getmeili/meilisearch:latest

Once the server is running, you can communicate with it using HTTP. The simplest use case is indexing documents into an index and querying them. Here is an example using Python.

import requests

docs = [
    {"id": 1, "title": "AI in Finance", "text": "How AI is changing banks"},
    {"id": 2, "title": "AI in Law", "text": "How AI helps legal teams"},
]
requests.put(
    "http://localhost:7700/indexes/articles/documents",
    json=docs
)

Searching is just as easy.

import requests

query = "ai banks"
res = requests.post(
    "http://localhost:7700/indexes/articles/search",
    json={"q": query}
)
print(res.json())

The engine returns results in milliseconds. Typo tolerance, word proximity and relevance ranking work out of the box.

Meilisearch automatically handles synonyms if you configure them and allows custom sorting rules for attributes like price or date. It also supports faceting, filters and geosearch, which makes it suitable for e-commerce, travel apps, real estate listings and data-heavy dashboards.

Using Hybrid Search and AI Together

Hybrid search combines full-text search with semantic vector search.

Meilisearch supports semantic search through vector fields and enables the combination of both approaches. This helps you serve users who type vague queries or natural language questions.

The AI model provides embeddings that capture meaning, while Meilisearch handles the fast retrieval and ranking.

To add semantic search, you first generate embeddings for your documents using an AI model. Here is a simple example using OpenAI embeddings.

from openai import OpenAI
import requests

client = OpenAI()
def embed(text):
    out = client.embeddings.create(
        model="text-embedding-3-small",
        input=text
    )
    return out.data[0].embedding
doc = {
    "id": 3,
    "title": "AI in Insurance",
    "text": "How AI powers underwriting",
    "vector": embed("How AI powers underwriting")
}
requests.put(
    "http://localhost:7700/indexes/articles/documents",
    json=[doc]
)

When the user searches, you embed the query and compute similarity. You can mix this with keyword search results returned from Meilisearch. The combined ranking creates a better experience than either approach alone.

Using AI To Rewrite Queries

Users often type incomplete or unstructured queries. They might type “How does AI help banks?” instead of keywords.

You can use an AI model to rewrite this into something more search-friendly. The rewritten query produces better results in Meilisearch while still respecting the user’s original intent.

from openai import OpenAI
import requests

client = OpenAI()
def rewrite_query(user_query):
    prompt = f"Rewrite this for search: {user_query}"
    out = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}]
    )
    return out.choices[0].message.content
user_query = "how does ai help banks"
rewritten = rewrite_query(user_query)
res = requests.post(
    "http://localhost:7700/indexes/articles/search",
    json={"q": rewritten}
)
print(res.json())

This pattern improves accuracy for question-based searches across blogs, documentation platforms and knowledge bases. You can also use the model to normalise queries, remove ambiguous text, expand synonyms and fix spelling mistakes before they reach Meilisearch.

Deploying Meilisearch to the Cloud using Sevalla

You can deploy Meilisearch anywhere. It runs on a small server, a local machine or inside containers.

Self-hosting gives you full control and is usually preferred by technical teams who want to keep sensitive data in-house. You can choose any cloud provider, like AWS, DigitalOcean, or others to set up Melisearch. But I will be using Sevalla.

I am using Sevalla for two reasons:

Every platform will charge you for creating a cloud resource. Sevalla comes with a $50 credit for us to use, so we won’t incur any costs for this example.
Sevalla has a template for Melisearch, so it simplifies the manual installation and setup for each resource you will need for installation.

You will see the resources being provisioned for the application.

Once the deployment is complete, click on “Visit app”.

You now have a production-grade Melisearch server running on the cloud. You can use this to set up indexes for your database and use the JavaScript or other SDKs to interact with Melisearch.

Here is the full list of apis provided by Melisearch.

Conclusion

Meilisearch gives you a fast and elegant base for search. AI models add understanding and personalisation. When these two work together, you get a search experience that feels instant, adaptive and intelligent.

You can start small with keyword search and then add query rewriting, embeddings, hybrid search and reranking. You can also use suggestions, synonyms and filters to improve the user journey.

With its simple API, wide language support and strong ecosystem, Meilisearch makes it easy to build a search that feels right at home in any modern app.

Hope you enjoyed this article. Find me on LinkedIn or visit my website.

Agents 101 — Build and Deploy AI Agents to Production using LangChain

Manish Shivanandhan — Wed, 26 Nov 2025 04:41:21 +0000

Learn how Langchain turns a simple prompt into a fully functional AI agent that can think, act and remember.

AI agents are no longer futuristic ideas locked inside research labs.

Today, you can build one that reasons about questions, calls real tools, remembers past messages, and responds with a consistent structure.

LangChain makes this possible. It offers a framework that blends language models, Python functions, prompts, and memory into a single workflow.

In this tutorial, we will guide you through the process of creating a fully functional agent from scratch.

We will shape it into something that feels less like a script and more like a teammate that can think, act, and adapt in real time.

You can use this Google Colab notebook to follow along with the examples in this article.

The idea behind an agent

Think of an agent as a teammate with a brain and hands.

Press enter or click to view image in full size

The brain is the language model. The hands are the tools you give it. The rules you write in the system prompt decide how the teammate behaves.

When everything works together, you get a system that can plan, act, remember, and answer predictably.

The magic is that the agent decides when to use tools. You do not hardcode the logic. You let the model reason step by step and choose the right action.

A tiny but clever agent

Here is the smallest agent you can build.

# import the agent creation function
from langchain.agents import create_agent

# Define a tool for the agent to call
def get_weather(city: str) -> str:
    """Get weather for a given city."""
    return f"It's always sunny in {city}!"
# Create an agent with an LLM model along with the tools and a system prompt
agent = create_agent(
    model="gpt-5-mini",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)
# Run the agent
agent.invoke(
    {"messages": [{"role": "user", "content": "what is the weather in sf"}]}
)

This looks harmless, but something interesting is happening.

The moment you wrap get_weather inside tools, the model understands that it can call a function instead of guessing the weather.

LangChain transforms that plain Python function into a callable tool, describes it to the model, and allows the model to decide when to use it.

When you run agent.invoke, the agent sees the question, reasons that the weather is being asked, and then chooses to call get_weatherwith the argument sf.

You didn’t write any routing logic. You just gave the model a choice.

This is the essence of agents: you describe, and the model decides.

But real systems need consistency, structure, context, and memory.

You want the agent to follow rules, not improvise. You want it to reply in stable formats, not unpredictable paragraphs. You want it to remember the user.

The next example brings all these pieces together to form a production-ready workflow.

Building a Real-World AI Agent

Let’s start by defining a system prompt. This tells the LLM how it should behave.

SYSTEM_PROMPT = """You are an expert weather forecaster, who speaks in puns. You have access to two tools:
- get_weather_for_location: use this to get the weather for a specific location
- get_user_location: use this to get the user's location
If a user asks you for the weather, make sure you know the location. If you can tell from the question that they mean wherever they are, use the get_user_location tool to find their location."""

Here, the system prompt acts like a job description. It defines how the agent should think, what it should care about, and when it should use each tool.

The more specific you are, the more stable the behaviour becomes.

Notice how the rules are written in plain English. Models respond very well to simple, direct instructions. This is how you stop them from drifting into creative chaos.

Now let’s build the tools our model can call.

Tools are just Python functions, but LangChain wraps them so the model can call them at the right moment.

In this part, we will create two tools:

A tool that returns the weather for any city.
A tool that figures out the user’s location based on context passed into the agent.

Before we write the code, here is the idea: The agent should not guess anything. If it needs information, it must call the correct tool. This makes the system predictable and safe.

Let’s write the two tools our agent will need.

from dataclasses import dataclass
from langchain.tools import tool, ToolRuntime

# ---------------------------------------
# Tool 1: Returns weather for a given city
# ---------------------------------------
@tool
def get_weather_for_location(city: str) -> str:
    """
    A simple tool that returns weather information.
    In a real system, this could call a weather API.
    """
    return f"It's always sunny in {city}!"
# ---------------------------------------
# Context object for injecting user info
# LangChain will attach this to runtime
# so tools can access user-specific data.
# ---------------------------------------
@dataclass
class Context:
    user_id: str
# ---------------------------------------
# Tool 2: Returns user location using context
# ---------------------------------------
@tool
def get_user_location(runtime: ToolRuntime[Context]) -> str:
    """
    A context-aware tool.
    It reads the user_id from runtime.context and returns
    the user's location. You can replace this with a real
    database or user profile lookup.
    """
    user_id = runtime.context.user_id
    # Simple rule: user_id "1" lives in Florida, others in SF.
    return "Florida" if user_id == "1" else "SF"

The first tool is straightforward: the agent calls it when it already knows the city.

The second tool is the interesting part. Instead of taking direct arguments, it receives a runtime object.

LangChain injects runtime data so tools have access to user context without passing it manually. That context might include user ID, permissions, preferences, or anything else relevant to the task.

This means your agent does more than answer questions. It adapts its behaviour based on who is using it. You get personalised responses without adding complicated logic inside the agent itself.

ToolRuntime may look complex, but it only serves a simple purpose. It allows tools to automatically access context passed into the agent. These include user ID or preferences, without you manually forwarding those values every time.

This keeps the tool logic clean while still enabling personalised behaviour.

With just a small dataclass and a tool decorator, LangChain gives you a clean way to build context-aware tools that make your agent feel smarter, more responsive, and more human.

Teaching the Brain How to Behave

The language model is the agent’s brain. It decides how to interpret questions, when to call tools, and how to phrase responses.

To keep it stable and predictable, we configure it before building the agent.

Before showing the code, here is what we are doing:

Choosing which model the agent will use.
Setting how creative it should be.
Controlling how long it can think.
Limiting how much text it is allowed to generate.

These settings decide how the agent behaves in every conversation.

Let’s initialise the model.

from langchain.chat_models import init_chat_model

# ---------------------------------------
# Configure the language model
# ---------------------------------------
model = init_chat_model(
    # The model to use for reasoning and tool-calling
    "gpt-5-mini",
    # How creative the model can be.
    # Lower values = more factual, consistent answers.
    temperature=0.5,
    # Maximum time (in seconds) the model can take to respond.
    timeout=10,
    # Upper limit on response length.
    # Helps control cost and prevents overly long messages.
    max_tokens=1000
)

Language models behave differently depending on their configuration:

Temperature controls creativity. A low temperature makes the agent consistent and predictable. A higher one makes it more playful, but also more risky.

Timeout controls patience. If a model gets stuck, this prevents requests from hanging forever.

Max tokens control cost and structure. Restricting output size forces the agent to stay concise and prevents runaway responses.

When you wrap a model with init_chat_model, you freeze these settings.
This ensures your agent behaves the same way every time.

In production, this kind of consistency matters. It keeps your system stable and prevents unpredictable behaviour that could break downstream logic.

Shaping the Output So You Can Trust It

Up to this point, the agent can think and act. But its answers still come as free-form text, which is risky in real systems.

Production applications need consistent fields, stable structures, and predictable formatting.

To achieve this, we define a response schema. LangChain uses this schema to force the model to respond in a clean, structured way.

Before showing the code, here is what you are doing:

Creating a data class that represents the exact shape of the final answer.
Telling LangChain to use this schema when parsing the model’s output.
Ensuring every response is machine-readable and safe to process.

Let’s define the response structure.

from dataclasses import dataclass

# ---------------------------------------
# Define the exact structure the agent must return
# ---------------------------------------
@dataclass
class ResponseFormat:
    # A playful weather message generated by the model
    punny_response: str
    # Optional field for conditions like "sunny", "cloudy", etc.
    weather_conditions: str | None = None

This is where the agent becomes production-ready.

Instead of letting the model write any paragraph it wants, you give it a strict format. LangChain ensures the final response follows the schema exactly.

This means:

The location of each piece of information is always the same.
Your code never has to guess what the model meant.
Errors drop because the structure is enforced.
Logging, debugging, and testing become far easier.
Downstream services don’t need regex or parsing hacks.

By shaping the output, you turn a creative model into a dependable system. It still speaks naturally, but the underlying data stays clean, stable, and safe to use.

Memory Gives the Agent a Sense of Continuity

An agent without memory acts like it has amnesia. It forgets who you are, what you asked earlier, and what tools it has already used.

To make an agent feel natural and consistent, it needs a way to store what happened in previous messages. LangChain provides this through a checkpointer. It helps us provide additional context to the agent every time we send a request.

Here is what we will be doing:

Creating an in-memory storage object.
Allowing the agent to save conversation history to that storage.
Making the agent remember user identity, previous answers, and tool calls.

This instantly makes the agent feel more like a real assistant.

Now, let’s add memory to the agent.

from langgraph.checkpoint.memory import InMemorySaver

# ---------------------------------------
# Simple in-memory storage for conversation history
# ---------------------------------------
checkpointer = InMemorySaver()

You can see that we have used Langgraph to call ImMemorySaver. LangChain and LangGraph are separate libraries that work well together.

LangChain handles tools, prompts, schemas, and model interaction, while LangGraph manages the control flow and memory features.

Now with memory enabled, the agent can remember who the user is, recall previous questions, keep track of tool results and continue the conversation naturally

It no longer asks “Who are you?” repeatedly. It doesn’t treat every question as brand new. It behaves as if the conversation has context and flow.

InMemorySaver keeps everything in RAM. This is perfect for demos, tests, and local development.

But memory must survive restarts in production. For that, we can replace the saver with a real database like Redis or Postgres.

With a persistent checkpointer, your agent remembers everything across sessions, servers, and deployments.

Memory is what turns a tool-calling script into a companion that understands continuity.

Putting the Agent Together

Everything we built so far, model, tools, system prompt, context, memory, and response format, now comes together to form a complete agent.

This is where the system stops being a set of separate parts and starts behaving like one intelligent unit.

Let’s use the system prompt, tools, context, response format and memory and build our agent.

from langchain.agents import create_agent
from langchain.output_parsers.tools import ToolStrategy

# ---------------------------------------
# Create the final agent by combining:
# - model: the brain
# - system_prompt: the rules
# - tools: the actions it can take
# - context_schema: user-specific info
# - response_format: structured outputs
# - checkpointer: memory for continuity
# ---------------------------------------
agent = create_agent(
    model=model,
    system_prompt=SYSTEM_PROMPT,
    tools=[get_user_location, get_weather_for_location],
    context_schema=Context,
    response_format=ToolStrategy(ResponseFormat),
    checkpointer=checkpointer
)
# ---------------------------------------
# Thread ID groups all messages into a single session.
# Reusing the same ID lets the agent remember context.
# ---------------------------------------
config = {"configurable": {"thread_id": "1"}}
# ---------------------------------------
# Invoke the agent with:
# - a user message
# - the session config
# - the user context (user_id)
# ---------------------------------------
response = agent.invoke(
    {"messages": [{"role": "user", "content": "what is the weather outside?"}]},
    config=config,
    context=Context(user_id="1")
)
# Print the final structured output
print(response['structured_response'])

This is the moment everything connects.

The agent follows a predictable internal sequence: read the prompt rules, examine the conversation history, choose whether to call a tool, run the tool with the correct arguments, and finally format the response according to your schema. This loop repeats for every message.

ToolStrategy ensures that the model’s final response strictly follows the dataclass schema you defined. Without it, the model might return loosely formatted text.

With ToolStrategy, LangChain parses and validates the output so your application always receives clean, predictable data.

The agent now has:

a model to think
a prompt to guide behaviour
tools to take action
context to personalise responses
memory to stay consistent
a schema to format output

When the user asks what the weather is outside, the agent begins by reading the rules in the system prompt to understand how it should respond. It then checks whether it already knows the user’s location, and if not, it calls the get_user_location tool using the context that was injected when the request was made.

Once the agent knows the city, it calls get_weather_for_location to fetch the weather details. Finally, it combines everything and returns a neatly structured response that follows the ResponseFormat schema you defined.

The thread ID acts like a conversation session. If you send more messages with the same ID, the agent remembers who the user is, what tools were called and earlier questions or answers

This creates real conversational continuity.

Clean, reliable output

ResponseFormat(punny_response="I found you — you're in Florida, so the forecast is sun-sational! No clouds about it: it’s always sunny in Florida. Don’t foget your shades — that’s a bright idea!", weather_conditions="It's always sunny in Florida.")

When you print structured_response, you don’t get text blobs or guesses. You get a neat Python object that exactly follows the schema you defined.

This makes the agent safe to integrate with dashboards, APIs, automations and backend systems.

No extra parsing. No brittle logic. Just predictable output.

A second call with the same thread_id makes the agent respond in the same pun-packed tone while keeping context. It knows you are still the same person in the same conversation.

ResponseFormat(punny_response="You're welcome! Glad I could brighten your day - I'm always here to "weather" your questions. Want an hourly or 7-day outlook?", weather_conditions=None)

The thread_id works like a session key. Every request sent with the same thread_id shares the same memory state.

This is how the agent remembers earlier questions, tool responses, or user details across multiple messages. Changing the thread_id starts a fresh conversation.

This is what makes agents feel coherent rather than robotic.

Moving to production

Once the quickstart becomes familiar, taking the agent to production is simply about adding structure and discipline.

The tools you wrote as placeholders should now do real work, and the in-memory storage should be replaced with a proper database so that memory survives restarts.

Your API needs authentication to protect access, and LangSmith tracing should be enabled so every tool call and model decision can be monitored.

The system prompt must stay clear and consistent to avoid drift, and the model settings, like temperature, max tokens, and model choice, should be tuned to balance cost and reliability.

Production agents also need safeguards around rate limits, timeout handling, tool failures, and observability. Adding retries, circuit breakers, structured logging, and LLM error handling ensures the system stays stable under real workloads.

Through all of this, the core agent pattern remains unchanged. You only strengthen the environment around it to make the entire system stable, predictable, and ready for real users.

Conclusion

Agents are not magic. They are predictable systems built from simple parts.

A model that follows instructions. Tools that do things. Prompts that set the rules. Memory that ties a conversation together. And schemas that keep the output clean.

Once you understand how these pieces fit, you can build an agent that feels polished, helpful, and ready for real users.

It can fetch data, store context, call APIs, and answer in structured ways without you writing the logic by hand.

That is what makes LangChain so powerful. It lets you focus on the behavior you want, not the plumbing underneath.

Hope you enjoyed this article. Sign up for my free newsletter TuringTalks.ai for more hands-on tutorials on AI. You can also visit my website.

Build, Manage, and Ship Python Projects the Easy Way using Poetry

Manish Shivanandhan — Mon, 24 Nov 2025 15:08:53 +0000

A guide to understanding Python Poetry, how it works, and how to use it in your next Python project.

Python development looks simple from the outside. But managing real projects is rarely easy.

You need to install packages, update them, avoid version conflicts, create virtual environments, and prepare your project for distribution.

Many beginners think they can handle everything with pip and venv. This works for small scripts, but becomes messy once your project grows.

Poetry solves this problem by giving you one clean workflow for managing Python projects from start to finish.

Poetry brings structure to your project. It automates package management, creates virtual environments independently, and prepares your project for building and publishing.

It replaces many scattered tools, bringing clarity and reliability. With Poetry, you focus on writing code while it takes care of the setup.

Poetry is also very helpful for AI projects. It locks exact dependency versions, which prevents sudden breaks when libraries like transformers, torch, or langchain release updates that can change model behaviour or API outputs.

This article explains how Poetry works, how to use it with examples, and how it compares with other alternatives. The goal is to make Poetry simple to understand, even if you are new to Python.

The Problem Poetry Tries to Solve

Modern Python projects need many moving parts.

You install libraries from PyPI, update them over time, track versions to keep the project stable, and share those versions with your team. You also need to package your project if you want others to use it.

The traditional way of using requirements.txt and pip install does not solve everything.

Dependencies can break when a new version is released. Two developers may use different versions without knowing. You may forget which environment you used. When you want to package the project, you often need tools like setuptools and wheel.

Poetry brings all these pieces together. It uses one file, pyproject.toml, to define everything.

It installs packages in a clean virtual environment. It locks versions to avoid surprises. And it can build and publish your package with a couple of commands.

Getting Started with Poetry

Poetry is easy to start with.

You install it once, and it works on any Python project. Run this command to install Poetry on your system:

pipx install poetry

Once installed, you can start a new project using:

poetry new my_project

This creates a folder with a basic structure. It includes a pyproject.toml file. This file is the heart of your project. It includes your project name, version, description, and dependencies.

[tool.poetry]
name = "myapp"
version = "0.1.0"
description = ""
authors = ["Manish Shivanandhan <manish@example.com>"]
readme = "README.md"

[tool.poetry.dependencies]
python = "^3.12"


[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

If you want to add Poetry to an existing project, you use:

poetry init

This asks you simple questions about your project and creates the configuration file.

This command will guide you through creating your pyproject.toml config.

Package name [myapp]:
Version [0.1.0]:
Description []:
Author [Manish Shivanandhan <manish@example.com>, n to skip]:
License []:
Compatible Python versions [^3.12]:

Would you like to define your main dependencies interactively? (yes/no) [yes]
You can specify a package in the following forms:
  - A single name (requests): this will search for matches on PyPI
  - A name and a constraint (requests@^2.23.0)
  - A git url (git+https://github.com/python-poetry/poetry.git)
  - A git url with a revision (git+https://github.com/python-poetry/poetry.git#develop)
  - A file path (../my-package/my-package.whl)
  - A directory (../my-package/)
  - A url (https://example.com/packages/my-package-0.1.0.tar.gz)

Package to add or search for (leave blank to skip):

Would you like to define your development dependencies interactively? (yes/no) [yes]

Now you can install packages using:

poetry add <package_name>

Poetry will install the package inside its own virtual environment. You do not need to run venv manually. To run your Python program, you use:

poetry run python main.py

Or you can enter the environment:

poetry shell

This simple workflow becomes natural very quickly.

Understanding pyproject.toml

The pyproject.toml file holds the data that defines your project. Poetry fills this file when you add or remove dependencies. An example of a simple file is:

[tool.poetry]
name = "weather"
version = "0.1.0"
authors = ["Manish"]

[tool.poetry.dependencies]
python = "^3.10"
requests = "^2.32.0"
[tool.poetry.group.dev.dependencies]
pytest = "^8.2.0"

This single file replaces setup.py, requirements.txt, and many manual steps. Poetry acts as a manager for everything inside it.

Building a Sample App

Imagine you are creating a simple weather app that calls an API. After creating a poetry project, you add a dependency:

poetry add requests

Then you write a Python script:

import requests

def get_weather(city):
    url = f"https://wttr.in/{city}?format=3"
    response = requests.get(url)
    print(response.text)
get_weather("London")

To run it:

poetry run python weather.py

Poetry locks the version of requests so your app works the same for everyone. If a new version is released and breaks something, you are safe because Poetry keeps your locked version.

When you want to build your project for publishing, you run:

poetry build

This command creates a file you can upload to PyPI:

poetry publish

This kind of simplicity is why Poetry has become a favourite among developers.

The Lock File

One of the quietly powerful features of Poetry is the lock file. When you add a package, Poetry writes exact versions to poetry.lock. This file ensures your project behaves the same across machines. If someone clones your project, all they need is:

poetry install

Poetry reads the lock file and installs the exact same versions you used. This helps with debugging because nothing changes silently after installation.

Comparing Poetry With Other Tools

Poetry is not the only tool for managing Python projects. To understand why developers choose Poetry, it helps to compare it with other popular options. Here are three alternatives and how they differ.

Poetry vs Pip and Virtual Environments

Pip is the default Python package installer, and venv creates isolated environments. These two tools have been used together for years. They work fine for simple scripts but require manual steps for real projects.

You create a virtual environment manually:

python -m venv env

Then you activate it, install packages, update requirements.txt, and manage version conflicts yourself. Packaging the project is a separate process entirely.

Poetry automates all of this. It creates the environment, tracks versions, and builds packages. The workflow is cleaner and more modern. Pip and venv feel manual compared to Poetry’s automated approach.

If you only need a quick script, pip and venv are enough. But for repeatable and sharable projects, Poetry wins by a wide margin.

Poetry vs Pipenv

Pipenv was created to make pip easier to use. It combines pip and virtual environments into a single workflow. Many people thought Pipenv would become the main Python tool, but it has struggled with performance and reliability issues.

For example, installing packages in Pipenv can be slow. Pipenv also uses a Pipfile instead of pyproject.toml, which makes it less aligned with modern Python standards.

A basic Pipenv command to install requests looks like:

pipenv install requests

Poetry does the same with:

poetry add requests

The biggest difference is stability. Poetry resolves dependencies faster and more reliably. It works well for large projects. Pipenv is simpler than raw pip but still less polished than Poetry.

Poetry vs Hatch

Hatch is another modern tool for managing Python projects. It also uses pyproject.toml, so it follows the same standards as Poetry.

Hatch is known for being flexible and fast. It is popular among users who handle packaging, testing, and versioning.

Hatch can create environments using:

hatch env create

Dependencies are managed using sections in the configuration file. Hatch can feel more advanced, and it focuses more on packaging than dependency management.

The main difference is that Poetry tries to be an all-in-one tool for dependency management, environments, building, and publishing. Hatch gives more control but less of a guided experience.

For beginners and teams, Poetry feels smoother. Hatch is powerful for advanced users who want more customisation.

Why Poetry Feels Enjoyable to Use

One of the reasons developers enjoy Poetry is the feeling of clarity.

Everything is clean, predictable, and organized. When you open a Poetry project, you always know where to look.

You know that dependencies are managed properly. You know that your build will work. This reduces stress and makes you more confident.

Poetry handles things you might forget about. It creates environments, controls versions, and keeps your workspace clean. It also has a friendly command-line interface that guides you with helpful messages.

Another benefit is how easy it is to share your project. Anyone who wants to run your project only needs to run:

poetry install

This brings stability to teams and avoids many common issues.

When Poetry Might Not Be the Best Choice

Poetry is great for most projects, but there are cases where it may not be the best fit.

If your project is extremely small, you may not need the extra structure. If you work in an environment that already uses pip, conda, or another strict workflow, introducing Poetry may cause friction.

Poetry also tries to manage environments on its own. Some users prefer manual control. In those cases, tools like Hatch or plain pip may fit better.

But for the majority of Python developers, Poetry brings huge value with very little setup.

Conclusion

Poetry is one of the clearest and most useful tools in the Python ecosystem. It helps you manage dependencies, create environments, build packages, and publish them with ease. It brings structure and reliability to your projects, making your code more stable and easier to share.

If you are looking for a better workflow for your Python projects, Poetry is a great tool to use. It keeps your setup clean, prevents version problems, and gives you a smooth path from development to publishing. With a few commands, you can build strong and repeatable Python projects without the usual headaches.

Hope you enjoyed this article. Sign up for my free newsletter TuringTalks.ai for more hands-on tutorials on AI. You can also visit my website.

How to Compress Your Prompts and Reduce LLM Costs

Manish Shivanandhan — Fri, 21 Nov 2025 12:33:36 +0000

Microsoft just solved the hidden cost problem in AI with LLMLingua, making large language models faster, cheaper, and smarter.

Every developer working with large language models eventually faces the same challenge.

Prompts keep getting longer, models keep getting slower, and API bills keep getting higher.

Whether you’re building a retrieval-augmented generation(RAG) system or a chatbot that remembers past conversations, every extra token adds cost and latency.

Microsoft quietly introduced a fix that few people outside research circles noticed, with a project called LLMLingua.

It compresses prompts before sending them to a model, keeping only the most important information. The result is faster responses, smaller bills, and an easier path to scaling LLMs.

In this tutorial, we will look at how to use LLM Lingua to optimze our prompts and make them more efficient while saving costs.

The Problem Hidden in Plain Sight

When an LLM processes a prompt, every token counts toward your cost and the model’s attention limit.

For context-heavy applications, it’s common to hit the maximum token window long before you reach the useful part of your data.

Adding more context may help the model reason better, but it also slows down inference. Long prompts not only take more time to generate responses but also eat into your budget when using APIs like GPT-4 or Claude.

LLMLingua targets this problem directly by compressing prompts intelligently without retraining or modifying the underlying model.

What LLMLingua Does Differently

LLMLingua uses a smaller, compact language model, like GPT-2 Small or LLaMA-7B. It uses them to identify and remove non-essential tokens in a given prompt.

Instead of feeding thousands of tokens into your main model, you send a compact version that retains meaning.

This approach achieves up to 20x compression with negligible accuracy loss. In simple terms, LLMLingua lets your LLM read the same content in fewer words.

Working with LLMLingua

Getting started is simple. The library is available on PyPI and works out of the box.

pip install llmlingua

Once installed, you can import it into Python to begin compressing prompts.

Here’s how you can compress a large text prompt using LLMLingua.

from llmlingua import PromptCompressor

# Initialize the compressor
llm_lingua = PromptCompressor()

# Compress the prompt
prompt = "Sam bought a dozen boxes, each with 30 highlighter pens inside, for $10 each box..."

compressed_prompt = llm_lingua.compress_prompt(prompt, instruction="", question="", target_token=200)

print(compressed_prompt)

When you run this, you’ll get a dictionary like this:

{
  'compressed_prompt': 'Question: Sam bought a dozen boxes each with 30 highlighter pens...',
  'origin_tokens': 2365,
  'compressed_tokens': 211,
  'ratio': '11.2x',
  'saving': 'Saving $0.1 in GPT-4.'
}

You can also load different models depending on your resources.

# Use a more powerful compression model
llm_lingua = PromptCompressor("microsoft/phi-2")

# Or use a quantized model for GPUs with limited memory
# Requires: pip install optimum auto-gptq
llm_lingua = PromptCompressor("TheBloke/Llama-2-7b-Chat-GPTQ", model_config={"revision": "main"})

This simple setup can save hundreds of dollars in production if you’re processing long documents or chat histories.

Handling Long Contexts with LongLLMLingua

LongLLMLingua extends this concept to massive inputs like PDFs, transcripts, or multi-document retrievals. It reorders and filters context dynamically to ensure that the model sees only the most relevant sections.

Here’s how you might use it:

from llmlingua import PromptCompressor

llm_lingua = PromptCompressor()

compressed_prompt = llm_lingua.compress_prompt(
    prompt_list,
    question="What are the main regulatory changes in the last quarter?",
    rate=0.55,
    condition_in_question="after_condition",
    reorder_context="sort",
    dynamic_context_compression_ratio=0.3,
    condition_compare=True,
    context_budget="+100",
    rank_method="longllmlingua",
)

This works especially well in RAG systems where documents vary in length and relevance. By combining retrieval with compression, you can fit more context into your LLM without hitting token limits.

LLMLingua-2: Faster and Smarter

Microsoft’s team didn’t stop there. They introduced LLMLingua-2, which is faster and more general-purpose.

It uses data distillation from GPT-4 and a BERT-level encoder to improve compression fidelity.

This version handles out-of-domain data better and performs 3–6 times faster than the original.

from llmlingua import PromptCompressor

# Initialize LLMLingua-2
llm_lingua = PromptCompressor(
    model_name="microsoft/llmlingua-2-xlm-roberta-large-meetingbank",
    use_llmlingua2=True,
)
compressed_prompt = llm_lingua.compress_prompt(prompt, rate=0.33, force_tokens=['\n', '?'])

# Or use a smaller multilingual model
llm_lingua = PromptCompressor(
    model_name="microsoft/llmlingua-2-bert-base-multilingual-cased-meetingbank",
    use_llmlingua2=True,
)

For multilingual and enterprise scenarios, LLMLingua-2 offers the right balance between cost, accuracy, and speed.

Structured Prompt Compression

Sometimes, you want control over which sections of a prompt should be compressed.

LLMLingua supports structured compression using special tags. You can mark segments of text to compress at different rates or skip entirely.

structured_prompt = """<llmlingua, compress=False>Speaker 4:</llmlingua>
<llmlingua, rate=0.4> Thank you. And can we do the functions for content? Items I believe are 11, three, 14, 16 and 28, I believe.</llmlingua>
<llmlingua, compress=False>Speaker 0:</llmlingua>
<llmlingua, rate=0.4> Item 11 is a communication from Council on Price recommendation...</llmlingua>"""

compressed_prompt = llm_lingua.structured_compress_prompt(
    structured_prompt,
    instruction="",
    question="Summarize the meeting notes",
    rate=0.5,
)
print(compressed_prompt['compressed_prompt'])

This feature is especially useful in meeting summarization or note-taking systems where speaker tags or section headers must remain intact.

SecurityLingua: Compression as a Defense

A newer addition, SecurityLingua, uses security-aware compression to detect malicious jailbreak attempts.

It reveals harmful intent hidden within complex prompts and defends against attacks with 100x less token cost compared to traditional guardrails.

from llmlingua import PromptCompressor

securitylingua = PromptCompressor(
    model_name="SecurityLingua/securitylingua-xlm-s2s",
    use_slingua=True
)
intention = securitylingua.compress_prompt(malicious_prompt)

This model offers a unique approach: instead of filtering after generation, it prevents malicious instructions from reaching the model in the first place.

Integration with the Ecosystem

One of the reasons LLMLingua stands out is how seamlessly it fits into the modern AI ecosystem.

Instead of being a standalone research prototype, it’s already integrated into popular frameworks like LangChain, LlamaIndex, and Microsoft Prompt Flow.

This means you can plug it directly into your existing RAG or document-processing pipelines without rewriting code or changing your models.

For example, in LangChain, LLMLingua acts as a smart middle layer that compresses retrieved context before it reaches the LLM.

Imagine you’re using a retriever to pull documents from a knowledge base. Instead of sending those long texts straight to your model, LLMLingua filters out unnecessary tokens so your prompt stays concise and efficient.

Here’s how you can integrate it:

from langchain_classic.retrievers.contextual_compression import ContextualCompressionRetriever
from langchain_community.document_compressors import LLMLinguaCompressor
from langchain_openai import ChatOpenAI

# Initialize your base model
llm = ChatOpenAI(temperature=0)

# Create an LLMLingua-based compressor
compressor = LLMLinguaCompressor(model_name="openai-community/gpt2", device_map="cpu")

# Wrap your existing retriever with LLMLingua compression
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=retriever  # your existing document retriever
)
# Use it like a normal retriever, but now with smart compression
compressed_docs = compression_retriever.invoke(
    "What did the president say about Ketanji Jackson Brown"
)
pretty_print_docs(compressed_docs)

In this setup, the retriever first gathers relevant documents, and LLMLingua compresses them before passing them to the LLM. The model receives a condensed but information-rich prompt, which keeps token usage low while maintaining accuracy.

This integration works out of the box with any supported model on LangChain. It can be customized to use your preferred compression rate or model variant (like LLMLingua-2).

The result is a more efficient pipeline. Your LLM reads less but understands more.

Why LLM Lingua Matters

LLMLingua may not make headlines like GPT-5 or Gemini, but its impact is fundamental. It addresses the most expensive part of LLM workflows — context handling.

By removing redundant tokens and preserving intent, it transforms how developers build scalable AI applications.

Whether you’re summarizing regulatory data, processing long legal documents, or powering multilingual chatbots, LLMLingua gives you a new lever for optimization.

The takeaway is simple: the future of AI efficiency won’t just come from larger models, but from smarter ones, and smarter prompts.

Conclusion

Microsoft’s LLMLingua is more than a research project. It’s a quiet revolution in how we deliver information to LLMs. It lets developers stretch context limits, cut costs, and speed up inference — all without retraining a single model.

By learning to compress prompts intelligently, LLMLingua helps you talk to machines more efficiently. And in the world of large language models, saying more with less is exactly the kind of progress that matters most.

Hope you enjoyed this article. Signup for my free newsletter TuringTalks.ai for more hands-on tutorials on AI. You can also visit my website.