5 Self-Hosted and Open-Source Options for Agent Tool Calling

A tool calling platform sits between an agent framework and the SaaS accounts the agent acts in. Teams in regulated industries, and teams that want to avoid lock-in, often ask whether that layer can run inside their own infrastructure.

The answer depends on three separate facts:

• The software license, which decides what you may modify, fork or offer to others.
• The parts of the platform that ship in the package you can host.
• The calls the self-hosted copy still makes back to the company that built it.

We build AgentKit, which is one of the five options below, so this list says where it is the wrong choice and where the other options lead.

This guide first explains what a self-hosted tool calling platform runs and what open source, source-available and self-hosted commercial mean, then sets out how the five options were picked and compares them in one table. It then covers each option in its own section and the work you take on when you host the platform yourself, and closes with how to choose.

TL;DR

• Which tool-calling platforms you can run yourself depends on the license file in each repository, so this list reads every license and names it exactly.
• Composio's SDK and Arcade's MCP framework are MIT-licensed, while Nango is source-available under the Elastic License 2.0 and Pipedream's repository carries its own source-available license.
• Running the open code is a smaller job than running the platform, because the hosted service usually still holds credential storage, refresh, and connector upkeep.
• Scalekit is a commercial product that offers self-hosted, VPC, and air-gapped deployment and US/EU data residency. Its SDKs are MIT-licensed on GitHub, but the platform itself is not open source.
• Self-hosting makes sense when data residency, network isolation, or lock-in rules decide the question, and the team can own token storage, refresh, and connector maintenance.

What Does a Self-Hosted Tool Calling Platform Run?

An agent tool calling platform does more than expose tools. Hosting one yourself means running every layer that touches a user's credentials:

• Authorization: the OAuth flow each user completes to connect an app, usually through an authorization link or a connect page.
• Token storage and refresh: an encrypted vault for each user's access and refresh tokens, and the job that refreshes them before they expire.
• Connectors and tools: the catalog of app integrations and the tool definitions an agent can call.
• Execution: the service that runs each tool call with the right user's token and returns the result.
• Permissions: the rules that limit which tools an agent role may call.
• Audit: a per-call record of which user ran which tool, and when.

Most open code in this category covers one or two of these layers, such as an SDK or an MCP server framework. The comparison below shows which options let you host all of them.

What Is the Difference Between Open Source, Source-Available and Self-Hosted Commercial?

Three labels get used interchangeably in marketing copy, and each one grants different rights:

• Open source means the license meets the Open Source Definition, as MIT does: you can read, modify, fork, and offer the code to others.
• Source-available means you can read and run the code, but the license restricts something, such as offering the software to others as a managed service.
• Self-hosted commercial means the company ships a package you run in your own cluster under a paid agreement, usually without a public repository.

Nango's Elastic License 2.0 falls in the middle. It allows internal use and modification, and it bars you from offering the software to third parties as a hosted or managed service with a substantial part of its features.

For that reason, this guide calls Nango source-available. Pipedream's repository carries the Pipedream Source Available License Version 1.0, so it gets the same label.

How Did We Pick and Evaluate These Five Options?

An option made the list if it publishes code you can run or documents a way to host the platform yourself, and if it handles per-user authorization for agent tool calls. Each one is then judged on five points:

• License: the exact license in the repository's LICENSE file, or commercial where the platform itself has no public repository.
• What you host: the parts of the platform that run on your own infrastructure.
• What still calls home: the hosted services a self-hosted copy still depends on.
• Per-user authorization: whether each tool call runs with the end user's own connected account.
• Deployment routes and plan: Helm, cloud marketplace, VPC or air-gapped installs, and whether the route needs an enterprise plan.

How Do the Five Self-Hosting Options Compare?

The table below compares five options on the facts that decide a self-hosting project: the license, what you run, what still depends on the hosted service, and whether per-user authorization is part of the package.

Each license named here comes from the repository's LICENSE file or the project's deployment docs. Cells say "not published" where the company gives no public statement.

What Are the Best Self-Hosted and Open-Source Tool Calling Options?

Each entry below states the license first, then what the package contains and where it stops. Order follows how much of the platform you can run on your own hardware, starting with the fully open code and ending with the weakest fit for this category.

1. Composio for an MIT-Licensed SDK on a Hosted Platform

Best for: Teams that want permissively licensed client code and the widest catalog, and accept a hosted service behind it.

Composio's repository is licensed under the MIT License, with Sampark Inc. as the copyright holder, and it has about 30.7k GitHub stars. The README describes sessions that expose a hosted MCP endpoint, and its development section covers building the monorepo for contributors.

Composio's enterprise page lists self-hosting as an Enterprise-exclusive feature, and it does not mention on-prem, VPC or air-gapped deployment.

Key Functionalities

• MIT-licensed code: You can read, fork and modify the SDK without license restrictions.
• Hosted MCP endpoints: Each session exposes an endpoint that Composio runs.
• Enterprise self-hosting: Listed as a paid feature, with deployment details not published.
• Catalog size: Composio claims 1,500+ apps, a figure that comes from Composio itself.

Pros:

• Permissive license for the code in the repository
• Large catalog and fast first call

Cons:

• The repository does not document self-hosting the platform
• Credential storage and refresh stay with the hosted service unless you buy Enterprise

Pricing: See Composio's pricing page. This list does not compare free tiers.

Verdict: Composio fits teams that value an MIT codebase and breadth, and it is a weaker fit for teams that must keep tokens inside their own network by default.

2. Nango for Source-Available Code With an Open Self-Host Path

Best for: Code-first teams that want to read and run the engine, and need only API authorization from the free version.

Nango's README says it is available under the Elastic License, and the LICENSE file is Elastic License 2.0. The license bars offering the software to others as a hosted or managed service, so Nango is source-available and this guide never calls it open source.

The repository has about 12.9k stars. The README lists three ways to run it: Nango Cloud, your own cloud account through BYOC, or self-hosting.

Key Functionalities

• Free self-hosting: Nango's docs say the free version includes only API authorization.
• Gated features: Syncs, actions, webhooks, the MCP server, the dashboard and logs are available in Nango Cloud or Enterprise self-hosted.
• BYOC: Runs Nango in your own cloud account.
• Code-first functions: Integrations are written as code.

Pros:

• Readable source under a license that allows internal use and modification
• Three deployment routes in the README

Cons:

• The free self-hosted tier leaves out actions, the MCP server and logs
• Elastic License 2.0 restricts managed-service use, so it cannot back a competing hosted product

Pricing: See Nango's pricing page. Enterprise self-hosting terms are not published.

Verdict: Nango suits teams that want to own the authorization layer and write their own integration code, and it is a poor fit for teams that expect the full agent toolset in the free self-hosted package.

3. Arcade for MIT-Licensed MCP Servers and a Helm-Deployed Platform

Best for: Teams that build their own MCP tools and want the option to run the whole platform in a Kubernetes cluster.

Arcade's arcade-mcp framework is MIT-licensed, with Arcade AI as the copyright holder, and the repository has about 1.1k stars.

Arcade's deployment docs describe three platform routes: a cloud marketplace deployment in your own cloud account, a Helm install on a Kubernetes cluster you manage, and hybrid MCP servers that run in your environment and connect to Arcade Cloud. The deploy page states no license for the engine itself.

Key Functionalities

• Standalone MCP servers: Run over stdio or HTTP with your own access tokens.
• Resource Server Auth: Production HTTP endpoints validate OAuth 2.1 bearer tokens against your identity provider.
• Helm platform install: Full platform on a cluster you manage end to end.
• Marketplace deployment: Azure is available as a managed app, AWS through a private offer, and GCP is in progress.

Pros:

• MIT license on the tool framework
• Several deployment routes, including a Helm chart for the full platform

Cons:

• The engine license is not stated on the deploy page
• Hybrid MCP servers still connect to Arcade Cloud

Pricing: See Arcade's pricing page. This list does not compare free tiers.

Verdict: Arcade works for teams that already write MCP servers and want a supported route to host the platform, and the engine license needs a direct question to Arcade before a legal review.

4. Scalekit for VPC, Air-Gapped and Data-Residency Requirements

Best for: Enterprise teams that need per-user, per-tool authorization with the platform running in their own network.

AgentKit is our commercial product. Its SDKs for Node.js, Python, Go and Java are MIT-licensed on GitHub, but the platform has no public repository, so it isn't open source. It appears on this list because it can run inside your infrastructure. We offer self-hosted, VPC, and air-gapped deployment and US/EU data residency.

Our self-hosting docs describe a Helm chart installed on Kubernetes 1.27 or later, with PostgreSQL 15 or later and Redis 6.2 or later, and they state that self-hosting requires an enterprise license.

Key Functionalities

• Per-user connected accounts: Each user authorizes once through an authorization link, and every call runs with that user's connected account.
• Per-tool scopes: A virtual MCP server exposes only the tools you pick for an agent role, and a read-only session token hides every write tool.
• Token vault: AES-256 at rest, with BYOK through your own GCP Cloud KMS key.
• Air-gapped installs: Listed as a supported environment. Connectors for apps inside your network need no internet access, while SaaS connectors still need outbound HTTPS to their provider.
• Log streaming: On Enterprise, tool call and connected account events stream to Datadog, CrowdStrike, or Google SecOps, and Scalekit takes requests for other destinations.

Pros:

• Deployment choices cover self-hosted, VPC and air-gapped
• 600+ connectors and 30,000+ tools, with per-tool scope

Cons:

• Only the SDKs are open source, so you cannot fork or audit the platform itself
• Self-hosting needs an enterprise license, you operate the cluster, database and cache, and you register your own OAuth app with each provider because Scalekit's shared OAuth credentials aren't available

Pricing: See scalekit.com/pricing for list prices. Self-hosting requires an enterprise license.

Verdict: AgentKit fits regulated teams that need the authorization layer inside their own boundary, and it is the wrong choice for teams that require a forkable open-source codebase.

5. Pipedream, a Weaker Fit With Open Components and a Hosted Connect

Best for: Teams that want to reuse Pipedream's pre-built integration components in their own code.

Pipedream's GitHub repository holds the pre-built integration components, along with docs and the roadmap, and has about 11.6k stars. Its LICENSE file is the Pipedream Source Available License Version 1.0, which makes the code source-available.

Pipedream's Connect documentation describes a hosted service, and it does not document self-hosting the platform. Pipedream is a weaker fit for this category, and it is listed so the license question has a clear answer.

Key Functionalities

• Open components: Pre-built integration components live in the public repository.
• Hosted Connect: Credentials and tokens go to Pipedream over HTTPS.
• Per-user accounts: Connect handles authorization per external user on the hosted service.

Pros:

• Large library of readable integration components
• Hosted per-user authorization

Cons:

• No documented route to self-host Connect
• The component license restricts use more than MIT does

Pricing: See Pipedream's pricing page. This list does not compare free tiers.

Verdict: Pipedream suits teams that want to borrow component code, and teams that must self-host the credential layer should look at the other four options.

When Is Self-Hosting Worth It, and What Do You Take On?

Self-hosting pays off when a rule outside engineering decides the architecture:

• Data residency laws, network isolation requirements, FedRAMP or HIPAA obligations, and customers who forbid third-party token storage are the usual triggers.
• Our self-hosting docs list the same drivers: auth data that must stay in one region, an auth service that cannot be reachable from the public internet, and environments with no outbound access.

Absent such a rule, a hosted platform is cheaper to run.

Hosting the platform moves three jobs onto your team:

• The first is token storage: you protect refresh tokens at rest, rotate keys and answer audit questions about them.
• The second is token refresh: you keep refresh working across providers whose rules change.
• The third is connector upkeep: each provider API change becomes your ticket, since the platform company's connector fixes reach you only as releases you deploy.
• Running the databases and caches under the platform adds on-call load.

The free or open parts of a platform rarely include all of that. Nango's free self-hosted version covers API authorization only, Composio lists self-hosting as an Enterprise feature, and Arcade's hybrid MCP servers still connect to Arcade Cloud.

For a broader comparison, the best tool calling platforms for AI agents list scores eight platforms on the same criteria, and the agent tool calling pillar explains the six layers a platform must cover.

Which Self-Hosting Option Should You Choose?

The right option depends on how much of the platform must run inside your network. Composio's MIT code suits teams that accept a hosted platform, and Arcade's Helm install suits teams that write their own MCP servers. Nango suits teams that want to run the authorization engine under the Elastic License 2.0, and Pipedream suits teams that only want its components.

When the whole authorization layer has to sit inside your boundary, Scalekit is built for that. It runs self-hosted, in a VPC or air-gapped environment, keeps per-user connected accounts and per-tool scopes, and makes no calls back to Scalekit once installed.

Whichever option you pick, ask which calls a self-hosted copy still makes home, and budget for token storage, refresh, and connector upkeep. To see how AgentKit deploys in your environment, read the AgentKit deployment options.

FAQs

What is a self-hosted agent tool calling platform?

It is a tool calling platform that runs on your own infrastructure instead of the provider's cloud, including the OAuth flows, the token vault, the connectors, tool execution and audit logs. Arcade's Helm install, Nango's Enterprise self-hosting and Scalekit document running the full platform yourself, and Composio lists self-hosting as an Enterprise feature.

Is there a fully open-source agent tool calling platform?

Not among the five options here. Composio's and Arcade's MIT-licensed code covers the SDK and the MCP server framework, Nango's code is source-available under the Elastic License 2.0, Pipedream's components carry a source-available license, and Scalekit's platform is commercial, with MIT-licensed SDKs.

Is Composio open source?

The Composio repository is licensed under the MIT License, which is an open-source license. The hosted platform behind it is a commercial service, and Composio lists self-hosting as an Enterprise feature.

Is Nango open source?

Nango is source-available. Its code is licensed under the Elastic License 2.0, which allows internal use and modification and bars offering the software to others as a managed service.

Can I self-host an agent tool calling platform?

Yes, with limits. Nango offers a free self-hosted version for API authorization, Arcade documents a Helm install and cloud marketplace routes, and Scalekit offers self-hosted, VPC and air-gapped deployment under an enterprise license. Composio lists self-hosting under Enterprise.

What do I give up by self-hosting?

You take over token storage, token refresh, connector upkeep, and the operation of the databases underneath. Some features may also sit outside the self-hosted package, as with Nango's free tier, which leaves out actions, the MCP server, and logs.

Which options support per-user OAuth?

Composio, Arcade, Scalekit, and Pipedream Connect all authorize calls per user on their platforms. Nango's free self-hosted version includes API authorization, and its docs do not say how per-user connections apply to it, so ask Nango before relying on it.