DEV Community: Manish Shivanandhan

Why Your “Simple Deploy” Turned Into a Week of Infrastructure Work

Manish Shivanandhan — Tue, 05 May 2026 04:40:19 +0000

If you are running production workloads, this is for you.

Not side projects. Not early-stage experiments. Not a single-service app with low traffic.

This is for teams shipping real systems. Systems with users, uptime expectations, and release pressure.

Because at that stage, your deploy process is no longer a convenience. It is part of your product.

And right now, for most teams, it is the weakest part.

The Promise You Were Sold

Every modern stack makes the same promise.

Shipping is easy. Deploying is automated. Infrastructure is abstracted away.

Push your code. Watch it go live. That promise works , until it doesn’t.

And when it breaks, it does not fail gracefully. It expands.

A “simple deploy” turns into a multi-day investigation across systems you never intended to own.

Not because your team is careless. Because the model itself assumes you will take on more responsibility than it admits.

The Hidden Contract You Are Already Operating Under

When you deploy today, you are not just shipping code.

You are agreeing to run a distributed system of tools.

You own the build pipeline. The container lifecycle. The runtime configuration. The network rules. The secrets layer. The scaling logic. The observability stack.

Each of these is presented as a separate concern. In reality, they are tightly coupled.

And you are the only layer holding them together. That is the hidden contract.

You Are Already Acting Like a Platform Team

If your deploy process involves CI pipelines, container registries, cloud services, environment variables, and monitoring tools, you are not just an application team anymore. You are running a platform.

You are defining how code moves from commit to production. You are deciding how failures are handled. You are shaping how services communicate.

That is platform engineering work.

The issue is not that this work exists. The issue is that most teams take it on unintentionally, without the structure, tooling, or dedicated ownership a real platform team would require.

The Cost Is Not Complexity. It Is Time

It is easy to describe this problem as “complexity.”

That undersells it.

The real cost shows up in how your team spends its time.

Deploys that should take minutes stretch into hours. Then days.

Engineers context-switch from product work into debugging CI caches, fixing misconfigured secrets, or tracing network failures across services.

Releases slow down. Not because your team cannot build features, but because shipping them becomes unpredictable.

Onboarding gets harder. New engineers do not just learn the codebase. They have to learn your deployment system.

None of this appears on a roadmap. But it directly impacts how fast you can move.

Why “It Works on My Machine” Still Exists

We were supposed to have solved this.

Containers. Infrastructure as code. Reproducible builds.

Yet the gap between local and production still shows up at the worst possible moment.

Because the problem was never just environment parity.
It is system parity.

Your local setup does not include the same limits, permissions, network paths, or scaling behavior as production.

Those differences only surface when everything is wired together.
Which means they surface during deploys.

Fragmentation Is the Root Problem

Modern tooling did not remove infrastructure complexity.
It redistributed it.

Instead of managing servers, you manage integrations between services.

Instead of a single failure domain, you have many.

A deploy can fail because of a CI issue, a registry timeout, a secret misconfiguration, a networking rule, or a scaling limit.

Each lives in a different system. Each requires different context.
Individually, these tools are well-designed. Collectively, they form a system that is hard to reason about under pressure.

This Model Breaks as You Scale

This only works while your system is small.
But production systems do not stay small.

More services mean more pipelines. More configurations. More failure points.

Over time, the effort required to maintain your deployment system grows faster than the product itself.
That is the inflection point.

Where engineering time shifts away from building features and toward maintaining the machinery that ships them.

If you are already feeling that shift, it is not temporary. It is structural.

At some point, there is a question that becomes hard to ignore: Why are you still managing this yourself?

Not because you cannot. But because it is no longer clear that you should.

The Shift Toward Platforms

This is where Platform as a Service changes the model.

Not by adding more tools. But by taking ownership of the system those tools create.

A PaaS defines a path from code to production. That path is opinionated, constrained, and consistent.

Those constraints are not limitations. They are what remove entire categories of failure.
Instead of assembling a deployment pipeline, you adopt one.

What You Stop Paying For

Moving to a PaaS is often framed as convenience. For production teams, it is closer to cost removal.

You stop spending time deciding how builds run, how services are exposed, how scaling is configured, how logs are collected.

You stop debugging the integration points between those decisions. You trade flexibility for predictability.

And for most teams, predictability is the constraint that actually matters.

From Infrastructure Work Back to Product Work

The biggest change is not in your architecture.
It is in your allocation of engineering effort.

Time spent debugging deploys shifts back to building features.
Time spent maintaining pipelines shifts to improving the product.
Deploys become routine again.

Not because they are simpler in theory, but because the system around them is controlled.

Collapsing the Stack

The advantage of a PaaS is not abstraction. It is consolidation.

Build, deploy, runtime, and observability are integrated into a single system.

There are fewer layers to coordinate. Fewer places to look when something fails. And fewer decisions to get wrong.

Platforms like Sevalla, Railway, and Render are pushing this further by tightening the loop between code and production, reducing both the number of systems involved and the surface area developers need to understand.

The goal is operational clarity.

The Trade-Off You Are Actually Making

The common objection is control. And it is valid.

You give up the ability to customize every layer of your infrastructure.

But in practice, most teams are not using that control to create differentiation. They are using it to keep a fragile system running, and it’s what keeps teams stuck maintaining systems they shouldn’t own.

Every custom configuration adds another failure point. Another dependency. Another thing to maintain under pressure.
The trade-off is not control versus convenience.

It is control versus reliability.

When This Becomes Urgent

You do not need a major outage to justify a change.
The signals show up earlier.

Deploys feel unpredictable. Releases slow down. Engineers spend more time on pipelines than product logic. Onboarding takes longer than it should.

These are not isolated issues.

They are indicators that your current model is not scaling with your system.

What a “Simple Deploy” Actually Means

A simple deploy is not one that feels easy when everything works. It is one that continues to work as your system grows.

It is predictable. Failures are rare. When they happen, they are easy to diagnose.

And most importantly, it does not require your engineers to think about infrastructure to ship code.

That outcome is not achieved by adding more tools. It is achieved by reducing the system you have to manage.

Closing Thought

Your deploy did not turn into a week of infrastructure work because you missed something. It turned into that because you are operating a model that expects you to.

You can continue investing in that model. Or you can adopt one where deploying is a solved problem.

For production teams, that is no longer a philosophical choice. It is an operational one.

The Hidden Tax of Infrastructure: Why Your Team Shouldn’t Be Running It Anymore

Manish Shivanandhan — Wed, 22 Apr 2026 06:19:29 +0000

Most engineering teams do not set out to manage infrastructure. They start with a product idea, a customer need, or a business problem.

Infrastructure enters the picture as a means to an end. Servers need to be provisioned. Databases need to be configured. Networks need to be secured. At first, this work feels necessary and even empowering. It gives teams control.

But over time, that control turns into a burden.

What begins as a few Terraform scripts or cloud console clicks evolves into a growing layer of responsibility.

Teams find themselves maintaining deployment pipelines, debugging networking issues, rotating credentials, patching systems, and responding to incidents unrelated to their product logic.

This is the hidden tax of infrastructure. It is not a line item in your budget, but it is paid every day in engineering time, cognitive load, and lost focus.

Infrastructure is not a one-time cost

A common mistake teams make is treating infrastructure as a setup task. Something you “get right” once and move on from.

In reality, infrastructure is a continuous system. It changes with scale, traffic patterns, security threats, and team structure.

Every component you introduce adds a long tail of operational work. A load balancer is not just a load balancer. It requires configuration tuning, monitoring, failover planning, and periodic upgrades. A database is not just storage. It brings backup strategies, replication concerns, indexing decisions, and performance tuning.

Even with infrastructure-as-code tools, the maintenance burden does not disappear. It becomes codified, but it still exists. Engineers must review changes, manage state, handle drift, and respond when things break.

The cost compounds quietly. It shows up in slower delivery cycles, longer onboarding times for new engineers, and increased risk during deployments. It is not visible in sprint planning, but it is always there.

The cognitive load problem

One of the most underestimated aspects of infrastructure management is cognitive load.

Modern systems are complex. Distributed architectures, microservices, container orchestration, and multi-region deployments all introduce layers of abstraction that engineers must understand.

When a team owns its infrastructure, every engineer becomes partially responsible for this complexity. Even if you have dedicated platform engineers, application developers still need to understand enough to debug issues and deploy changes safely.

This context switching has a real cost. An engineer working on a feature must also think about container resource limits, networking rules, observability gaps, and failure modes. Instead of focusing on business logic, they are juggling operational concerns.

Cognitive load slows teams down. It increases the chance of mistakes. It makes systems harder to reason about. And it reduces the time engineers spend on the work that actually differentiates your product.

Reliability is harder than it looks

Running infrastructure in production means owning reliability. This includes uptime, latency, data integrity, and incident response. Many teams underestimate how difficult this is to do well.

High availability is not just about redundancy. It requires careful design, testing, and ongoing validation. Failover mechanisms must be exercised. Monitoring systems must be tuned to detect real issues without creating noise. Incident response processes must be defined and practised.

When something goes wrong, the cost is immediate and visible. Engineers are pulled into debugging sessions. Customers are affected. Business metrics drop. Postmortems are written. Action items are created, which often add more infrastructure complexity.

Over time, teams build layers of safeguards and tooling to improve reliability. But each layer adds more to manage. The system becomes harder to change. The risk of unintended consequences increases.

This is the paradox of self-managed infrastructure. The more you invest in reliability, the more complex your system becomes, and the more effort it takes to maintain that reliability.

Security and compliance never stand still

Security is another dimension where the hidden tax becomes clear. Threats evolve constantly. Best practices change. Compliance requirements grow more stringent.

When you run your own infrastructure, you are responsible for staying ahead of these changes. This includes patching systems, managing access controls, encrypting data, auditing logs, and responding to vulnerabilities.

Even small gaps can have serious consequences. A misconfigured permission, an outdated dependency, or an exposed endpoint can lead to breaches. The cost of prevention is an ongoing effort. The cost of failure can be catastrophic.

Compliance adds another layer. For teams in regulated industries, infrastructure must meet specific standards. This often requires documentation, audits, and controls that go beyond basic security practices.

All of this work is necessary, but it does not directly contribute to your product’s value. It is part of the hidden tax you pay for owning infrastructure.

The illusion of control

One of the main reasons teams continue to manage their own infrastructure is the belief that it gives them control. They can customise everything. They can optimise for their specific needs. They are not dependent on external platforms.

While this is true in theory, in practice, the level of control is often overstated. Most teams do not need deep customisation at the infrastructure level. They need reliability, scalability, and predictable behaviour.

The control you gain comes at the cost of responsibility. Every customisation must be maintained. Every optimisation must be monitored. Every deviation from standard patterns increases the risk of issues.

In many cases, teams end up recreating capabilities that are already available in managed platforms. They build internal tooling for deployment, scaling, and monitoring, only to maintain it indefinitely.

The question is not whether you can manage your own infrastructure. It is whether you should. Most small to mid-sized teams should not be managing infrastructure at all. If it is not your competitive advantage, it is a distraction.

The rise of PaaS as an alternative

Platform-as-a-Service, or PaaS, changes the equation. Instead of managing infrastructure directly, teams deploy applications to a platform that handles the underlying complexity.

With PaaS, concerns like provisioning, scaling, load balancing, and patching are abstracted away. Engineers focus on code and configuration, not on servers and networks.

This does not eliminate all operational work, but it shifts the responsibility. The platform provider handles the heavy lifting. Your team benefits from standardised, battle-tested infrastructure without having to build and maintain it.

PaaS also reduces cognitive load. Developers interact with a simpler interface. Deployments become more predictable. Observability is often built in. This allows teams to move faster and with greater confidence.

Importantly, PaaS aligns infrastructure with application needs. Instead of designing infrastructure first and fitting applications into it, teams define what their application requires, and the platform provides it.

Heroku was the first to bring PaaS mainstream. Since Heroku is shutting down, I moved to Sevalla for its simplicity and the speed with which new features, especially agentic tools, are introduced. Here is a list of alternatives.

Speed is a competitive advantage

In most markets, speed matters. The ability to ship features quickly, respond to feedback, and iterate on ideas is a key competitive advantage.

Infrastructure management can slow this down. Changes require coordination. Deployments carry risk. Debugging issues takes time away from development.

By reducing the infrastructure burden, PaaS enables faster delivery. Teams can deploy changes more frequently. They can experiment with new ideas without worrying about underlying systems. They can recover from failures more quickly.

This is not just about engineering efficiency. It has a direct impact on business outcomes. Faster delivery leads to better products, happier customers, and a stronger market position.

Cost is more than the cloud bills

When teams evaluate infrastructure strategies, they often focus on direct costs. Cloud bills, reserved instances, and resource utilisation are measured and optimised.

But the hidden tax of infrastructure is mostly indirect. It includes engineering time spent on maintenance, the opportunity cost of delayed features, and the risk of outages and security incidents.

These costs are harder to quantify, but they are often larger than the direct costs. A single incident can consume days of engineering time. A delayed feature can impact revenue. A security breach can damage a reputation.

PaaS may appear more expensive on paper, but it often reduces total cost when you account for these hidden factors. It shifts spending from operational overhead to product development.

Rethinking ownership

The core question is not about tools or technologies. It is about ownership. What should your team own, and what should it delegate?

Your product is your core asset. It is what differentiates you in the market. Infrastructure, while critical, is a means to support that product.

By continuing to manage infrastructure, teams take on responsibilities that do not directly contribute to their goals. They pay the hidden tax in time, focus, and risk.

PaaS offers a way to rebalance this. It allows teams to delegate infrastructure concerns and focus on building value.

The shift is not always easy. It requires changes in mindset, tooling, and processes. But for many teams, it is a necessary step.

Because the real cost of infrastructure is not what you pay your cloud provider. It is what you give up to run it yourself.

From Metrics to Meaning: How PaaS Helps Developers Understand Production

Manish Shivanandhan — Mon, 20 Apr 2026 08:25:47 +0000

Modern production systems generate more data than most developers can realistically process.

Every request emits logs. Every service exports metrics. Every dependency introduces another layer of signals.

In theory, this should make systems easier to understand. In practice, it does the opposite.

Dashboards become dense, alerts become noisy, and when something breaks, the same questions still come up. What is actually wrong? Who is affected? Where do you even start?

The problem is not observability. It is interpretation.

Most teams are not short on metrics. They are short on meaning.

And that gap exists because developers are often forced to reason about infrastructure when they should be focused on application behaviour.

Metrics exist to describe systems, but without the right level of abstraction, they become another layer of complexity.

This is where modern PaaS platforms change the equation.

They do not remove metrics. They turn them into signals that developers can actually use.

This article breaks down five metrics that consistently matter in production systems. More importantly, it shows how a PaaS helps translate these metrics into something actionable, without requiring developers to act as infrastructure operators.

I’ll be using the Sevalla dashboard to explain these metrics but other platforms like Railway and Render will have similar metrics.

Latency Becomes a Clear Performance Signal

Latency is the most direct representation of user experience. It tells you how long your system takes to respond.

When latency increases, users feel it immediately. Pages slow down. APIs become unreliable. Even small delays impact engagement.

Most developers know to look at percentiles like p95 or p99 instead of averages. The slowest requests are what define perceived performance.

But in many environments, understanding latency is not straightforward.

A spike could come from inefficient code. Or from cold starts. Or from scaling delays. Or from network routing issues. Developers are forced to investigate layers they did not build.

This is where a PaaS changes the role of latency.

Instead of being a starting point for infrastructure debugging, latency becomes a clean signal of application performance. Scaling, routing, and resource allocation are handled by the platform. What remains is a clearer relationship between code and outcome.

When latency increases, developers can focus on what they actually control. Queries, logic, dependencies.

The metric stays the same. The meaning becomes clearer.

Error Rate Becomes a Reliable Indicator of Failure

Error rate answers a simple question. Is the system working or not?

It is usually measured as the percentage of requests that fail due to server-side issues. These are failures users cannot recover from. A broken checkout flow or a failed API call directly impacts trust.

In theory, error rate should be one of the easiest metrics to act on.

In practice, it rarely is.

Errors can come from application bugs, but also from timeouts, resource limits, failed deployments, or unstable instances. Developers end up correlating errors with infrastructure events just to understand what happened.

This slows everything down.

A PaaS reduces this ambiguity.

Failures caused by scaling, instance crashes, or transient infrastructure issues are handled at the platform level. Retries, isolation, and recovery mechanisms are built in.

What remains is a tighter link between error rate and application correctness.

When the error rate increases, it is far more likely to be something in the code or a dependency, not an invisible infrastructure issue.

This shifts the error rate from a noisy metric into a reliable signal.

Throughput Becomes Context Instead of a Problem

Throughput measures how many requests your system handles over time.

It provides context for everything else. Latency and error rate only make sense when you know how much traffic the system is handling.

A spike in latency during high traffic is expected. The same spike during low traffic is a warning sign.

But in many systems, throughput introduces operational complexity.

Traffic changes require scaling decisions. Teams define autoscaling rules, tune thresholds, and try to predict demand. When things go wrong, they revisit those decisions.

Developers end up thinking about capacity instead of behaviour.

A PaaS shifts this responsibility.

Scaling is automatic. Traffic spikes are absorbed by the platform. Developers do not need to decide how many instances should be running or when to scale.

Throughput becomes what it should be. Context.

It helps explain what is happening, without forcing developers to manage how the system adapts.

Resource Utilisation Moves Out of the Critical Path

Resource utilization measures how much CPU, memory, and I/O your system consumes.

Traditionally, this has been central to operating systems. High CPU or memory usage signals potential issues. Teams monitor these metrics to avoid failures and plan scaling.

But for most developers, resource utilization is not where value is created.

Yet in many environments, developers are still responsible for interpreting these signals. They tune memory limits, investigate CPU spikes, and try to optimise resource usage to keep systems stable.

This is operational work.

A PaaS changes the role of these metrics.

Resource management is handled by the platform. Allocation, scaling, and isolation happen automatically. Developers do not need to constantly watch CPU graphs or memory charts to keep the system running.

These metrics still exist, but they move into the background.

They become diagnostic tools rather than primary signals.

Developers can focus on performance at the application level, instead of managing how infrastructure behaves under load.

Instance Health Becomes Invisible by Design

Instance health tracks restarts, crashes, and lifecycle events.

In many systems, this is a critical metric. Frequent restarts indicate instability. Memory leaks, crashes, or resource exhaustion often show up here first.

Teams monitor instance health to catch issues early and prevent cascading failures.

But this also reveals something important.

Developers are aware of, and responsible for, the lifecycle of infrastructure.

They track restarts, investigate crashes, and try to stabilise the system manually.

A PaaS removes this responsibility.

Unhealthy instances are restarted automatically. Load is redistributed. Capacity is maintained without manual intervention.

Instance health does not disappear, but it no longer requires constant attention.

It becomes part of the platform’s internal behaviour, not something developers need to actively manage.

From Metrics to Meaning

These five metrics have not changed.

Latency still reflects performance. Error rate still reflects correctness. Throughput still reflects demand. Resource utilization still reflects efficiency. Instance health still reflects stability.

What changes is how much work it takes to interpret them.

In lower-level environments, developers have to connect these signals themselves. A latency spike leads to checking throughput, then resource usage, then instance behaviour. Each step requires context, assumptions, and time.

This is where complexity accumulates.

A PaaS reduces that gap.

It handles scaling, recovery, and resource management so that metrics map more directly to application behaviour. The signals become easier to interpret because fewer variables are exposed.

Instead of asking multiple questions across layers, developers can move more directly from symptom to cause.

Why This Matters for Developers

Most developers do not want to manage infrastructure.

They want to build features, ship improvements, and respond to user needs.

But as systems grow, operational responsibility expands. Monitoring becomes more complex. Debugging requires more context. A significant portion of time shifts from building to maintaining.

Metrics are part of this shift.

They are necessary, but they also reflect how much of the system you are responsible for understanding.

A PaaS does not eliminate metrics. It reduces the effort required to make sense of them.

It ensures that when something changes in production, the signals developers see are closer to the reality they care about.

Application behaviour. User experience. System correctness.

The Real Advantage Is Clarity

The goal is not to have fewer metrics.

It is to have metrics that mean something without requiring deep infrastructure reasoning.

These five metrics form a complete picture of system health. But their real value depends on how directly they map to what developers control.

The more layers you have to think about, the harder mapping becomes.

A good PaaS removes those layers.

It turns metrics from raw data into usable signals.

And that shift from metrics to meaning is what allows developers to understand production systems without being buried under them.

From Prompt Engineer to Agent Engineer: The 7 Skills You Need to Build AI Agents

Manish Shivanandhan — Wed, 15 Apr 2026 20:12:20 +0000

Discover the key skills you need to build AI agents that thrive in real-world environments, moving beyond crafting prompts to engineering robust systems.

The world of artificial intelligence is rapidly evolving. Just a few years ago, being a “prompt engineer” was about crafting clever instructions for a language model.

But times have changed. Today, building AI agents that function in the real world requires much more.

The role is far broader and demands a diverse set of skills. This transition from a focus on crafting prompts to engineering sophisticated systems is like moving from following a recipe to becoming a chef.

As we delve into these seven essential skills, you’ll see exactly where to focus your efforts to become a successful “agent engineer.”

The Changing Landscape of AI Engineering

There’s an identity shift happening in technology today. What once was the realm of prompt engineers is now evolving into something much broader—agent engineering.

In the past, crafting well-designed prompts was enough when working with general-purpose AI models like GPT. However, today’s AI agents are not just responding to questions; they’re performing actions, making decisions, interacting with databases, and much more. This means the skills required have expanded significantly.

When building AI systems that perform real functions, like booking flights or processing refunds, writing effective prompts is just a starting point. The real challenge lies in engineering systems that can function seamlessly and handle unexpected situations.

It’s like moving from being a cook who follows recipes to becoming a chef who understands all aspects of culinary creation. A chef knows about ingredients, techniques, and workflows, and this is the mindset you need to become an agent engineer.

System Design: The Foundation of AI Agents

Effective system design is the cornerstone of building reliable AI agents.

When constructing an agent, you’re creating a complex system with multiple components that must work together harmoniously. This involves an architecture in which data flows smoothly, and every component understands its role. You might have a language model making decisions, tools executing actions, and databases storing states. Like an orchestra, these elements must harmonise without stepping on each other’s toes.

Thinking of it like designing a complex software backend can be helpful. You’ll deal with situations where one component may fail and must handle requests that require coordination between several parts. If you have experience with system design, this might sound familiar. If not, it is crucial to start learning, as software systems, like AI agents, require solid structure and thoughtful orchestration.

Here is a wonderful resource put together on System Design - https://github.com/karanpratapsingh/system-design

Tool and Contract Design: Establishing Clear Communication

Agents interact with the world through tools, and each tool operates on a contract. A contract is a set of clear expectations about inputs and outputs.

The importance of precise tool design cannot be overstated. Vague contracts lead agents to make assumptions, which can be catastrophic, especially in critical tasks like financial transactions.

For example, if a tool’s input schema says “user ID is a string,” the agent might interpret it in various unintended ways. But by specifying a pattern that must be matched, you guide the agent toward consistent, error-free operation.

Clear tool contracts are like the terms of a handshake agreement. When both sides know exactly what’s expected, operations run smoothly, reducing room for ambiguity and errors. This precision in design ensures that your agents function effectively without resorting to guesswork or imagination, qualities that are less than ideal in automated systems.

Mastering Retrieval Engineering

Retrieval Engineering, specifically Retrieval Augmented Generation (RAG), is a critical component in enhancing an agent’s performance. Instead of relying solely on pre-trained knowledge, RAG involves fetching relevant documents to enrich the model’s context. The quality of these retrieved documents directly affects the agent’s output, making this a complex yet essential skill.

Achieving optimal retrieval involves several factors. Documents must be split into appropriately-sized chunks—large enough to maintain context but small enough to avoid obscuring important details.

Additionally, embeddings, which the model uses to represent similar concepts, must be accurately aligned to ensure meaningful context. Finally, re-ranking mechanisms ensure the most relevant documents are prioritised. This deep discipline requires careful attention, but understanding its basics can significantly enhance your agent’s performance.

Reliability Engineering: Ensuring Consistent Agent Performance

Reliability is a non-negotiable aspect of agent engineering.

APIs can fail, networks can time out, and external services may go down unexpectedly. These situations can render your agent ineffective or stuck, trying to execute an unachievable task. Therefore, reliability engineering principles like implementing retry logic with back-off, setting timeouts to prevent indefinite hang-ups, and creating fallback paths are critical.

Think of these techniques as proactive measures to protect your system from cascading failures and ensure your agent can maintain a high level of performance, even under less-than-ideal conditions. While these concepts may be familiar to those with a background in backend development, they are crucial for any aspiring agent engineer who wishes to build robust and resilient systems.

Security and Safety: Protecting Your AI Systems

Security is a crucial concern in agent engineering.

Agents can be targets for attacks, such as prompt injections, where malicious instructions are embedded in user input to mislead the system. Without proper defences, an agent might inadvertently comply with harmful requests. Thus, it’s essential to apply security engineering principles to a new kind of system.

This involves implementing input validation to filter malicious requests, output filters to ensure responses adhere to policy, and permission boundaries to limit the agent’s actions. These measures protect your system from unauthorised manipulation and ensure the agent functions within safe and compliant parameters.

In this sense, security engineering is about anticipating potential vulnerabilities and reinforcing your system to prevent misuse.

Evaluation, Observability, and Product Thinking

An agent’s effectiveness can only be improved if its performance is well-evaluated. Techniques for evaluation, along with observability tools, allow you to track your agent’s actions, understand why decisions were made, and identify areas for improvement.

Tracing every decision, logging each tool interaction, and keeping a comprehensive timeline are essential practices for effective debugging and enhancing performance.

Beyond technical prowess, product thinking emphasises the human aspect of agent engineering. Agents should align with user expectations, offering clear feedback when confident or uncertain, and handle errors gracefully. Product thinking involves designing user-friendly systems that build trust and encourage use, even when unpredictable AI behaviour is involved.

Conclusion

Transitioning from a prompt engineer to a full-fledged agent engineer involves mastering a diverse skill set, much like a chef mastering the culinary arts.

By understanding system architecture, designing precise tool contracts, optimising information retrieval, ensuring reliable operations, fortifying security, and integrating evaluation and product thinking, you’re well on your way to building AI agents that perform seamlessly in the real world.

These seven skills are your recipe for success, paving the way for creating robust, reliable, and human-friendly AI systems. As the expectations for AI systems evolve, so too must our skills. The future belongs to those who adapt and grow with it.

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.