What are the main GaaS deployment models?

The main models are provider-hosted cloud, dedicated private cloud, customer-controlled local or on-premises deployment, and hybrid deployment across local and remote systems.

Is local GaaS completely private?

Only when every relevant model, tool, source, state store, log, and destination remains local. Remote tools, authentication, storage, or telemetry can make a local workflow partly hybrid.

When should a company choose private GaaS?

Private deployment may fit when stronger isolation, dedicated networking, controlled regions, enterprise identity, custom retention, and business-critical service commitments are required.

What is the main challenge of hybrid GaaS?

Hybrid GaaS creates a distributed data and responsibility path. Identity, networking, logs, versions, support, outages, and recovery must be coordinated across environments.

Is cloud GaaS always cheaper than local deployment?

No. Cloud reduces hardware and administration but may add recurring model, tool, storage, and usage charges. Local deployment adds hardware, maintenance, power, backup, and support costs.

How does Feluda support different GaaS deployment models?

Feluda can connect cloud or local AI providers, run desktop workflows, use local or remote MCP tools, and coordinate execution through Studio, RunFlows, and Schedule Manager.

GaaS Deployment Models: Cloud, Private, Local, and Hybrid

Agentic as a Service can be delivered through several deployment models.

The agent may run:

in a provider-managed public cloud;
in a dedicated private cloud environment;
on customer-controlled infrastructure;
on an individual device; or
across a hybrid combination of local and remote systems.

The deployment model affects more than where the model runs.

It also determines:

where data moves;
who operates the infrastructure;
how tools are connected;
how quickly the service can scale;
which systems remain available offline;
how credentials are stored;
how updates are controlled;
what the service costs; and
who is responsible when part of the environment fails.

There is no universally best model.

The right choice depends on the task, data, users, tools, risk, performance, and operating capability of the organisation.

The four main GaaS deployment models

Model	Main characteristic	Best suited to
Cloud GaaS	Provider operates the service on shared or logically isolated cloud infrastructure	Fast deployment and elastic scale
Private GaaS	Dedicated environment for one organisation	Stronger isolation and enterprise control
Local or on-premises GaaS	Customer-controlled hardware runs key components	Data sovereignty, offline work, and local systems
Hybrid GaaS	Work is divided across local, private, and cloud components	Mixed privacy, scale, and integration needs

These categories can overlap.

A private environment may run in a public-cloud region.

A local agent may call a remote model.

A cloud orchestrator may use an on-premises MCP server.

Buyers should review the complete execution path rather than relying only on the deployment label.

What is cloud GaaS?

Cloud GaaS is operated primarily in infrastructure managed by the provider.

The provider may manage:

agent runtimes;
AI models;
orchestration;
memory;
tools;
monitoring;
scaling;
backups;
updates; and
service availability.

Users normally access the service through a web application, API, or connected business system.

Cloud deployment is often the fastest way to begin.

It can support distributed users without requiring local installation or infrastructure management.

Benefits of cloud GaaS

Cloud GaaS can offer:

rapid onboarding;
elastic capacity;
centralised administration;
simpler remote access;
managed updates;
broad model availability;
standard integrations;
high service availability;
easier collaboration; and
predictable provider support.

It is especially useful when the service must support many users, changing demand, or several geographic locations.

Challenges of cloud GaaS

Cloud services may create concerns around:

remote data processing;
provider dependence;
region availability;
internet dependence;
changing model providers;
usage-based cost;
limited infrastructure control;
data retention;
subcontractors; and
service outages.

A cloud label does not reveal which third parties process the data.

Customers should request a complete data-flow and provider map.

What is private GaaS?

Private GaaS provides a dedicated environment for one customer or defined organisation.

It may run:

in a dedicated cloud account;
in a private virtual network;
in a sovereign cloud;
on managed private infrastructure;
in a dedicated provider environment; or
on customer-controlled cloud resources.

The provider may still operate the service, but the execution environment is more isolated than a normal shared service.

Benefits of private GaaS

Private deployment can provide:

stronger tenant isolation;
dedicated network controls;
customer-specific access policies;
selected model options;
private endpoints;
controlled regions;
custom retention;
more detailed activity records;
integration with enterprise identity; and
clearer change-management boundaries.

It may suit organisations with sensitive data, regulated processes, or established private-cloud operations.

Challenges of private GaaS

Private environments may require:

longer implementation;
higher minimum cost;
capacity planning;
customer networking work;
more complex support;
dedicated monitoring;
specialised maintenance;
slower feature adoption; and
clearer division of responsibility.

A private environment is not automatically secure.

Poor permissions, weak credentials, or unsafe tools remain dangerous.

What is local or on-premises GaaS?

Local or on-premises GaaS runs important components on infrastructure controlled by the customer.

This may include:

desktop computers;
workstations;
local servers;
private data centres;
factory systems;
branch offices;
edge devices; or
disconnected environments.

The local environment may host the model, agent runtime, workflow, tools, data, or all of them.

Benefits of local GaaS

Local execution may provide:

reduced remote data movement;
offline operation;
access to local files and databases;
lower network latency;
direct hardware control;
predictable data location;
closer integration with local equipment;
independence from some cloud outages; and
the ability to use private or open models.

It can be useful for confidential documents, restricted networks, local operations, and tasks that depend on nearby systems.

Challenges of local GaaS

The customer may need to manage:

hardware;
model downloads;
storage;
operating-system security;
local users;
updates;
model runners;
MCP servers;
firewalls;
backups;
power;
sleep and restart behaviour;
monitoring; and
device replacement.

Local execution transfers operational responsibility to the customer.

A sleeping laptop or stopped local service can interrupt scheduled work.

What is hybrid GaaS?

Hybrid GaaS divides execution across more than one environment.

For example:

a local model may analyse confidential files;
a cloud agent may coordinate the workflow;
an on-premises MCP server may retrieve internal records;
a remote model may handle non-sensitive reasoning;
a private store may hold task state; and
a cloud business application may receive an approved update.

Hybrid deployment is often the most flexible model.

It is also the most complex to understand and operate.

Benefits of hybrid GaaS

Hybrid deployment can combine:

local privacy;
cloud scale;
private-system access;
remote collaboration;
model choice;
workload routing;
resilience;
regional control; and
cost optimisation.

Different task stages can use the environment that fits them best.

Sensitive extraction may remain local while a general cloud model prepares a non-sensitive final draft.

Challenges of hybrid GaaS

Hybrid systems may introduce:

more network dependencies;
several identity systems;
inconsistent logs;
complex data movement;
difficult incident diagnosis;
model-routing uncertainty;
duplicated monitoring;
version mismatch;
local and cloud outages;
unclear support ownership; and
portability problems.

The organisation must know which component handled each task stage.

Compare data control

Cloud: Data is processed mainly in provider-managed environments.

Private: Data remains in a dedicated environment with stronger customer-specific controls.

Local: Data can remain on customer-controlled hardware when every connected component is also local.

Hybrid: Data location varies by task stage.

The phrase local AI can be misleading when remote tools, storage, logging, or model providers still receive information.

Always map the full data path.

Compare scalability

Cloud services usually offer the easiest elastic scaling.

Private environments may scale well but often require reserved capacity or planned expansion.

Local environments are limited by available hardware.

Hybrid systems can send suitable workloads to cloud capacity while retaining sensitive work locally.

Scaling should include more than compute.

Review whether human approvals, exception handling, monitoring, and support can scale with task volume.

Compare latency

Local execution can reduce latency when the model, tools, and data are near the user or device.

Cloud execution can be fast when network connections are reliable and the provider has nearby infrastructure.

Hybrid workflows may introduce delays when data moves between environments.

Measure the complete time to an accepted outcome.

One fast model call does not guarantee a fast multi-step task.

Compare resilience

Cloud services can provide managed redundancy across infrastructure and regions.

Private environments can offer dedicated resilience designed for one organisation.

Local environments may continue during internet outages but can fail because of device, power, storage, or local-service problems.

Hybrid environments can provide fallback options.

They can also fail when one required link between environments is unavailable.

A deployment plan should define what happens when each dependency fails.

Compare operational responsibility

Responsibility	Cloud	Private	Local	Hybrid
Infrastructure	Mostly provider	Shared or provider-managed	Mostly customer	Shared
Model runtime	Usually provider	Provider or customer	Customer	Shared
Local device health	Limited	Limited	Customer	Customer for local parts
Scaling	Mostly provider	Planned jointly	Customer	Shared
Updates	Mostly provider	Controlled jointly	Customer	Shared
Monitoring	Provider plus customer	Shared	Customer	Must be unified
Recovery	Provider-led	Shared	Customer-led	Coordinated

Contracts and operating documents should make these boundaries explicit.

Compare cost structures

Cloud GaaS may include:

subscriptions;
model usage;
tool usage;
storage;
task charges; and
support.

Private GaaS may add:

dedicated environments;
reserved capacity;
private networking;
implementation; and
premium support.

Local GaaS may include:

hardware;
electricity;
local storage;
administration;
backups;
upgrades; and
support labour.

Hybrid GaaS may combine every category.

Compare total cost per accepted outcome rather than only provider invoices.

Choose cloud GaaS when

Cloud deployment is often suitable when:

rapid deployment matters;
users are distributed;
demand changes;
standard integrations are sufficient;
data can be processed remotely;
provider-managed updates are preferred;
internet access is reliable; and
the organisation wants limited infrastructure responsibility.

Choose private GaaS when

Private deployment may fit when:

stronger isolation is required;
enterprise identity integration matters;
private networking is necessary;
data-region requirements are strict;
the service is business-critical;
dedicated capacity is valuable; and
the organisation can support a more involved implementation.

Choose local GaaS when

Local deployment may fit when:

data should remain on controlled devices;
offline operation is required;
local files or equipment are central;
low local latency matters;
remote processing is restricted;
customer-controlled models are preferred; and
the organisation can operate the environment.

Choose hybrid GaaS when

Hybrid deployment may fit when:

some data must remain local;
cloud scale is still useful;
workflows span legacy and cloud systems;
different models fit different stages;
remote users need access;
local resilience is required; and
the organisation can manage distributed operations.

Hybrid should be chosen for a clear reason, not as the default answer to every requirement.

Avoid accidental hybrid architecture

Many services become hybrid unintentionally.

A supposedly local workflow may still use:

remote authentication;
cloud logging;
hosted embeddings;
remote backups;
online model routing;
provider telemetry; or
cloud destinations.

Record each remote dependency.

Test offline behaviour when local independence is required.

Design identity across environments

Hybrid and private systems may use several identity layers.

Define:

user identity;
agent identity;
device identity;
workload identity;
tool identity;
service account;
approval identity; and
provider-support identity.

Avoid using one shared credential across local and cloud environments.

Access should remain attributable and revocable.

Unify observability

Distributed execution creates fragmented evidence.

A GaaS operator should be able to connect:

task identifier;
local activity;
cloud activity;
model calls;
tool calls;
approvals;
external actions;
errors;
retries; and
final status.

Use consistent identifiers and timestamps.

A final result should not become impossible to investigate because its steps occurred in different environments.

Plan deployment changes

A GaaS service may move between models over time.

Common transitions include:

cloud to private;
cloud to hybrid;
local to hybrid;
one provider to another;
one region to another; or
customer-managed to provider-managed operation.

Before migration, document:

workflows;
models;
tools;
accounts;
credentials;
state;
memory;
activity records;
schedules;
data;
permissions; and
acceptance tests.

Portability should be tested before it becomes urgent.

How Feluda supports flexible deployment

Feluda can support several agentic deployment patterns.

AI Providers can connect cloud services and local model runners.

Desktop operation can support workflows on customer-controlled computers.

MCP Servers can connect local or remote tools.

Studio can combine models, tools, branches, validation, and error handling.

RunFlows can expose workflow execution and intermediate output.

Schedule Manager can support recurring local or connected workflows.

This makes it possible to design local, cloud-connected, or hybrid GaaS capabilities.

The actual deployment classification depends on every model, tool, source, destination, log, and storage component in the workflow.

Deployment decision checklist

Before choosing a model, confirm:

the business outcome;
data sensitivity;
required regions;
internet dependence;
offline requirements;
latency target;
user locations;
model requirements;
local hardware;
tool locations;
source locations;
destination locations;
identity design;
scaling needs;
monitoring;
support ownership;
recovery;
total cost;
migration options; and
retirement process.

The practical conclusion

GaaS deployment is a distribution of responsibility.

Cloud deployment gives more operational responsibility to the provider.

Private deployment adds isolation and customer-specific control.

Local deployment gives the customer greater control and greater operational burden.

Hybrid deployment combines environments to meet mixed requirements, but it also creates the most complex data, identity, monitoring, and recovery path.

Choose the model by mapping the complete task.

Decide where each model, tool, source, state store, and destination should run.

Make responsibility explicit.

Test the environment under normal, offline, degraded, and recovery conditions.

The best deployment model is the one that meets the task's real privacy, performance, availability, and operational needs without adding complexity that the organisation cannot support.