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.

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.

  • 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: A bucket or container for uploaded files, brain files and run results. AWS S3, MinIO and Azure Blob Storage are supported. See Object storage.
  • 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.

  • 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 networks: Services 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.

superglue keeps uploaded files, Brain files, logos, tool output files and run results in one bucket or container. Set S3_PROVIDER to aws, minio or azure. Stored file references have the form s3://<bucket>/<key> for every provider. A move to another provider keeps these references when the bucket name and the object keys stay the same. The storage must support conditional writes (If-Match and If-None-Match on PUT). AWS S3, Azure Blob Storage and current MinIO releases support them.

Use a general-purpose v2 storage account without hierarchical namespace, and one private container.

  • Container: Set AZURE_STORAGE_CONTAINER_NAME. Set AZURE_STORAGE_PREFIX to the folder for raw uploads, for example raw.
  • Managed identity: Set AZURE_STORAGE_ACCOUNT_NAME and no key. superglue authenticates with DefaultAzureCredential and signs file links with a user delegation SAS. For a user-assigned identity, also set AZURE_STORAGE_MANAGED_IDENTITY_CLIENT_ID. In production, set AZURE_TOKEN_CREDENTIALS=ManagedIdentityCredential.
  • Account key: Set AZURE_STORAGE_CONNECTION_STRING, or set AZURE_STORAGE_ACCOUNT_NAME and AZURE_STORAGE_ACCOUNT_KEY. The storage account must allow shared key access.
  • Role: Assign Storage Blob Data Contributor to the managed identity on the storage account. If you assign it on the container only, also assign Storage Blob Delegator on the storage account. Without the account-level permission, the health check passes but uploads and downloads fail.
  • Browser access: Browsers upload and download files directly from the storage account. Add a Blob service CORS rule for the web app origin with the methods GET, HEAD, PUT and OPTIONS and the headers content-type and x-ms-blob-type. If the account restricts network access, allow your users’ networks as well as superglue.
  • Other clouds: Set AZURE_STORAGE_BLOB_ENDPOINT if the blob endpoint is not https://<account>.blob.core.windows.net.

Copy the objects with rclone. AzCopy does not support MinIO as a source.

  1. Create a container with the same name as the MinIO bucket. Container names have 3 to 63 lowercase letters, numbers and single hyphens. If the bucket name does not follow these rules, contact us before you move.
  2. Configure the two rclone remotes, for example with environment variables:
    Terminal window
    export RCLONE_CONFIG_MINIO_TYPE=s3
    export RCLONE_CONFIG_MINIO_PROVIDER=Minio
    export RCLONE_CONFIG_MINIO_ENDPOINT=http://localhost:9000
    export RCLONE_CONFIG_MINIO_ACCESS_KEY_ID=<MINIO_ROOT_USER>
    export RCLONE_CONFIG_MINIO_SECRET_ACCESS_KEY=<MINIO_ROOT_PASSWORD>
    export RCLONE_CONFIG_AZURE_TYPE=azureblob
    export RCLONE_CONFIG_AZURE_ACCOUNT=<storage account name>
    export RCLONE_CONFIG_AZURE_KEY=<storage account key>
  3. Copy the bucket while superglue still runs on MinIO:
    Terminal window
    rclone copy minio:<bucket> azure:<bucket> --checksum --transfers 16 --progress
  4. Stop superglue. Run the same rclone copy command again to copy the files written in the meantime.
  5. Compare the copy with the source. The result must report 0 differences:
    Terminal window
    rclone check minio:<bucket> azure:<bucket> --one-way
  6. Set S3_PROVIDER=azure and the Azure variables. Keep the prefix value from MINIO_BUCKET_PREFIX.
  7. Start superglue. Make sure that /v1/health reports objectStorage as ok and that an existing file opens.
  8. Keep the MinIO data until you have verified the move.
  • 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, connections and playbooks. See Role-based access control.
  • Metrics: A Prometheus-compatible endpoint for your monitoring stack. See Metrics and telemetry.
  • 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.