Skip to content

Self-hosting

Enterprise customers can run the full superglue platform inside their own perimeter: in a dedicated VPC in their cloud account, in a private cloud, or on-premise. The feature set is the same as superglue Cloud. Client data, credentials and model traffic never leave your environment.

Deployment options

Section titled “Deployment options”

superglue Cloud

Hosted by superglue in the EU or the US. Choose the region where your data lives. No infrastructure to run.

Your cloud account

Single-tenant deployment in your AWS, Azure or Google Cloud account, typically as a container service behind your own load balancer, with your managed database and object storage.

On-premise or private VM

Docker Compose on a virtual machine you operate, managed with the superglue setup script. Suits data centers and private clouds without a container platform.

Self-hosting is included in the Enterprise plan. Contact us to scope a deployment. A proof of concept with your own systems typically takes two to five days.

What you provide

Section titled “What you provide”
  • Compute: A container runtime. Kubernetes, Amazon ECS, or a Linux VM with Docker.
  • Database: PostgreSQL, for example Amazon Aurora, Azure Database for PostgreSQL, or a managed instance you already run.
  • Object storage: An S3-compatible bucket for uploaded files, system documentation and run results. AWS S3 and MinIO are supported.
  • Model access: An LLM provider for the agent. Supported providers are Anthropic, OpenAI, Google Gemini, Azure OpenAI, Amazon Bedrock and Google Vertex AI. Bedrock, Vertex AI and Azure OpenAI keep model traffic inside your cloud account.
  • Ingress: A TLS endpoint for the web app and the API, restricted to your network or an IP allowlist if required.
  • Secrets: A place to hold the deployment secrets, such as AWS Secrets Manager, Azure Key Vault, or a protected file on the host. Stored credentials are additionally encrypted at rest with a master key you own.

superglue provides the container image from a private registry, the deployment configuration, and the upgrade procedure.

Networking

Section titled “Networking”
  • Outbound: The application reaches client systems over the internet from your egress addresses. An egress proxy with an allowlist is supported when your security policy requires one.
  • Private systems: Systems inside other networks connect through the secure gateway. The gateway makes an outbound connection to your superglue instance, so no inbound rules are needed on the client side.
  • Local networks: Tool execution is blocked from reaching private and link-local addresses by default. The deployment configuration relaxes this only for the networks you name.
  • Sandbox: Agent scripts and transformations run in an isolated sandbox inside the container.

Identity and access

Section titled “Identity and access”
  • Single sign-on: Okta sign-in over OpenID Connect, with optional SCIM provisioning, group sync and automatic deprovisioning. See Single sign-on.
  • Access rules: Role-based access control for tools, systems, credentials and playbooks. See Role-based access control.
  • Metrics: A Prometheus-compatible endpoint for your monitoring stack. See Metrics and telemetry.

Operations

Section titled “Operations”
  • Scheduler: Scheduled runs are claimed by the application instances you designate. No separate worker fleet is needed.
  • Upgrades: superglue publishes versioned images. Upgrades are rolled out on a schedule you approve, with rollback to the previous version. Deployments on a single VM have a short restart window; container platforms with spare capacity upgrade without downtime.
  • Backups: Your database and object-storage backup policies apply. superglue stores no state outside them.
  • Support: Enterprise plans include a dedicated support channel and an SLA.