superglue: AI Agents for Enterprise ERP and System Integration

What superglue Solves and Who It Is For

Enterprise software integration has a long tail problem. The popular connectors between Salesforce and HubSpot are well-supported by existing iPaaS platforms. The difficult cases are the mid-market ERP systems, legacy SOAP services, niche vertical applications, and the data formats that differ per customer. Building and maintaining a separate connector for each of these requires ongoing engineering time that does not compound.

superglue is aimed at this problem. The README describes it as a system where agents learn how your systems work from your company's knowledge and perform the implementation that normally requires human coordination and engineering work. The practical use cases in the README include ERP migrations (Sage Intacct, NetSuite, SAP, Business Central, Acumatica), connecting internal systems to AI platforms like Claude or other LLMs, customer onboarding across diverse technology stacks, and managing data flows for organisations like universities that run CRM, fundraising, and database systems in parallel.

The target users are implementation consultants, operations engineers, and platform teams who manage integration work at scale and cannot afford to write and maintain a separate codebase per connection.

How superglue Agents Work

superglue is described as working with any REST, GraphQL, SOAP, file-based, or database system. The README lists a wide set of supported systems: ERP platforms (Sage Intacct, NetSuite, SAP, Dynamics 365, Business Central, Acumatica, QuickBooks, Xero), CRM and sales tools (Salesforce, HubSpot, Attio, Gong), databases (Postgres, MongoDB, Microsoft SQL Server, Redis, Supabase, PlanetScale, Snowflake, Databricks), messaging (Slack, Gmail, Zoom), payments (Stripe, PayPal, Adyen), and AI and LLM platforms (OpenAI, Anthropic, Gemini, Pinecone, Elasticsearch).

The README's example use case table illustrates the contrast in scope: a Sage Intacct migration that previously took 140 hours and 10-15 cleanup iterations per GL history entry is described as completing in under an hour with superglue agents mapping the transformation from a plain English description. The README frames this as agents performing the mapping, migration, and post-go-live synchronisation work end to end. This is an AI agent pattern, not a configuration-driven pipeline: the system interprets natural language descriptions of the desired mapping and generates the integration logic.

Self-Hosting superglue via Docker

superglue offers two deployment paths: a cloud-hosted service at app.superglue.cloud and a self-hosted option. The self-hosted path uses Docker Compose. The repository contains a docker-compose.yml file that defines three services: the superglue application server, a Postgres database, and a MinIO object store.

The .env.example file in the repository shows the required configuration. The application server uses two ports by default:

API_PORT=3002
WEB_PORT=3001

Authentication for the API requires setting a token:

AUTH_TOKEN=your-secret-token
NEXT_PUBLIC_SUPERGLUE_API_KEY=your-secret-token

The LLM provider is configurable. The .env.example notes that the best performance-to-price ratio at writing time is Gemini with gemini-2.5-flash, with the AI provider variable accepting OPENAI, GEMINI, ANTHROPIC, BEDROCK, VERTEX, or AZURE as values.

The scheduler server is controlled by a separate variable. The .env.example warns that only one scheduler instance should run at a time to avoid conflicts when using the same database. The Postgres and MinIO services are defined under the infra and all Docker Compose profiles, meaning they are not started by default and must be explicitly included when the infrastructure is not already managed externally.

Supported Systems and Integration Scope

The system catalogue in the README is broad. Beyond the ERP and CRM systems already mentioned, it covers DevOps (AWS, Google Cloud, Firebase, GitHub, GitLab, Heroku, Netlify, Vercel), analytics (Google Analytics, Amplitude, Segment, Mixpanel, Looker, PostHog, Datadog, Sentry), marketing (Google Ads, Meta Ads, Mailchimp, Klaviyo), HR and payroll (Workday, Gusto), e-commerce (Shopify, BigCommerce), identity (Auth0, Okta), and file systems (FTP, SFTP, SMB, Google Drive, Dropbox).

The README's scope claim is that superglue works with any system that has an API, database, or file connection. This is the architectural proposition of the product: rather than shipping a finite set of pre-built connectors, the agent interprets system documentation and API descriptions at runtime to build integration logic. The limitations of this approach are not documented in detail in the README; the depth and reliability of agent-generated integrations across the full listed catalogue will vary in practice.

Limitations and Design Trade-offs

The Functional Source Licence (FSL) used for the core superglue repository is not an open-source licence. FSL permits use, modification, and redistribution for non-competing purposes, but restricts using the software to compete directly with the licensor's cloud offering. Users who plan to build a commercial integration platform on top of superglue should review the FSL terms carefully. The client SDKs carry the MIT licence separately and have no such restriction.

The self-hosted deployment depends on maintaining the Docker infrastructure: Postgres for state, MinIO for file storage, and the superglue server itself. There is no documented migration path between superglue versions in the repository, and no GitHub releases are published; the software is distributed as a Docker image and an npm package referenced from the package.json.

The AI-agent-driven integration model means that integration quality depends on the quality of the LLM backing the agents. The .env.example configuration selects the LLM provider, and the README notes performance differences between providers. Teams running sensitive data through superglue should verify which provider processes their data and what the data handling terms are for that provider.

superglue vs. Traditional iPaaS Tools

Traditional integration platforms such as MuleSoft and Boomi provide a catalog of pre-built connectors managed through a visual development environment. The integration logic is expressed in a configured pipeline, and teams maintain that configuration over time. These tools work well when the source and destination systems are in the catalog and the mapping is deterministic.

superglue takes a different approach: agents interpret natural language descriptions of the desired integration and generate the mapping logic. This makes it faster to get a new integration started, particularly for systems not in any pre-built catalog. The trade-off is that the agent-generated logic is less predictable than a configured pipeline, and debugging a failure requires understanding what the agent produced.

MuleSoft and Boomi are commercial products with established enterprise support models and deep connector libraries. superglue is a newer platform (Y Combinator W25) with broader claimed scope but less proven track record. Claims about MuleSoft or Boomi's current feature sets should be verified from their own documentation.

Maintenance, Repository Structure, and Licence

The repository's default branch is main. The last push to main was on 2026-08-19. There are no GitHub releases; the project is distributed as a Docker image and via npm. The top-level package.json shows a Turborepo monorepo with packages under packages/ and plugins under plugins/. The scripts include turbo-based build, test, and type-check targets.

The repository contains a CLAUDE.md file in the root, indicating the maintainers have documented agent-specific rules for working with this codebase. It also contains eval directories for both tool evals and integration evals, suggesting the maintainers test the agent behaviour directly.

The core superglue server is FSL licensed. The client SDK packages carry the MIT licence and can be used in any project without FSL restrictions. Enterprise users who need contractual guarantees should contact the company directly, as no self-service SLA is documented in the repository.

Editorial conclusion

Engineering and operations teams that need to integrate or migrate data across ERP systems like NetSuite, SAP, or Acumatica, or connect internal systems to AI platforms, will find superglue's agent-driven approach meaningfully different from hand-rolled connectors. The platform targets the long tail of enterprise integrations where building and maintaining custom code per connection is cost-prohibitive. Users considering self-hosting should review the Functional Source Licence before deployment, as it is not an open-source licence and restricts some production uses. The client SDKs are MIT licensed separately. Check the .env.example for the full list of required environment variables before configuring a self-hosted instance.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. superglue-ai/superglue on GitHub