PRICING

Pricing For Self-Hosted Loft

You install Loft in one of your Kubernetes clusters. Then, you can connect additional Kubernetes clusters for your teams if needed. Everything runs on your company's private or public cloud infrastructure.
Pay monthly
Pay yearly and save 20%

Free

Explore Loft and set up self-service for your team for free.
$
0
per user
per month
Install Loft
  • 3 Users
  • 2 Kubernetes Clusters
  • Up to 5 Virtual Clusters
  • Self-Service Namespaces
  • Community Support
View All Features

Productive

Onboard your team with flexible per-user pricing for Loft.
$
20
per user
per month
Buy Now
  • Up to 100 Users
  • 10 Kubernetes Clusters
  • Up to 1,000 Virtual Clusters
  • Self-Service Namespaces
  • Sleep Mode & Auto-Delete
  • Email & Chat Support
View All Features

Enterprise

Enterprise-grade Loft deployments with best-in-class support.
Custom
Pricing
Request Pricing
  • Unlimited Users
  • Unlimited Kubernetes Clusters
  • Unlimited Virtual Clusters
  • Self-Service Namespaces
  • Sleep Mode & Auto-Delete
  • High-Availability Mode
  • Secrets Encryption
  • Audit Logging
  • Air-Gapped & VPC Support
  • White Glove Onboarding
  • Priority Support
View All Features

Compare Plans

Productive

Buy Now

Enterprise

Contact Sales
Kubernetes Access Control
User Limit

The user limit specifies the maximum number of users who can sign in and use Loft.

Once you exceed the user limit, Loft will not allow any additional users to be added and may block certain requests (e.g. create space or virtual cluster) if you remain above the user limit. A warning will be displayed in the UI if you are exceeding the user limit.

3 Users
100 Users
Unlimited
Connected Clusters

Loft provides multi-cluster support which means that Loft can run in one cluster and you can connect other clusters to your Loft instance to make these clusters available to your engineers.

2 Clusters
10 Clusters
Unlimited
Single Sign-On (SSO)

Loft provides integrations for all major single sign-on providers, including:

  • Okta, OneLogin
  • GitHub, GitLab
  • Azure Active Directory and LDAP
  • OpenID Connect
  • SAML2
  • and many more

You can even connect multiple authentication providers in Loft and let users choose how they want to sign in.

Group-Based Rules

Loft lets you create Teams, so you don't have to specify cluster access and resource limits for each individual users. Instead, you can select a team and define cluster access rules for each team member or you could create a shared cluster access with an aggregated limit that is enforced for the team itself and can be used by each team member.

If your SSO provider defines user groups, Loft will automatically create teams for each user group but you can also define additional teams in Loft independent of your SSO provider.

SSO Group Membership Sync

If your SSO provider defines groups for users, Loft will automatically create teams for each group and make sure users become part of the appropriate teams in Loft if they are part of the linked group as defined in your SSO provider's system.

Loft also keeps team memberships up-to-date, e.g. if you remove someone from a group in your SSO provider's system, the user will also be removed from the associated team in Loft.

Self-Service Namespaces
Spaces / Namespaces

Non-admin users should not be permitted to list, create or delete namespaces in Kubernetes. That's why Loft provides a virtual resource called Space which is a virtual abstraction for a Kubernetes namespace.

You can configure who can create and manage Spaces in each of the connected clusters. Each Space will directly map to a real Kubernetes namespace and since Loft does not have a separate database but only uses the state of your Kubenretes clusters, everything is always in sync, i.e. if a namespace is being deleted, the Space that represents this namespace will also be gone immediately.

Unlimited
Unlimited
Unlimited
Automatic Isolation

Loft allows you to define so called Space Constraints which allow you to enforce any kind of Kubernetes resource inside a Space, e.g. a NetworkPolicy or a LimitRange. If you define a NetworkPolicy as part of a Space Constraint, that means that when any user who is bound by this Space Constraint creates a Space, Loft will create a namespace and then add the NetworkPolicy to this namespace.

Loft also keeps Space Constraint resources in sync:

  • If a resource is (accidentially) deleted, Loft will automatically recreate it to ensure that the Space Constraint is enforced at all times.
  • If a Space Constraint changes (e.g. changing a NetworkPolicy), Loft will automatically update all resources in already created namespaces to match the updated resource inside the Space Constraint.
Automatic RBAC

RBAC is one of the most complicated and error-prone parts of Kubernetes. With Loft, you can rest assured that RBAC is configured with a "least permission required" mindset and all rules are kept up-to-date with zero manual effort.

Loft provides several ClusterRoles that are used for automatic RBAC but you can modify these roles or add new ones to fully customize access control for your users and teams.

Team & User Namespaces

With Loft, you can allow users to create namespaces for themselves but you can also allow them to create shared namespaces for their teams (typically mapped to SSO groups). Team-owned namespaces and the resources inside of them count towards the team's quotas rather than the user's individual limits and are automatically shared with all team members according to the access rules you configure in Loft.

On-Demand Sharing

Loft allows users to give other users and even entire teams access to their Spaces whenever needed. This can either be initiated via the UI but also via the CLI or even via kubectl. Users who gained access to a Space of another user may retrieve a kube-context to access the Space via Loft CLI and can also access the shared Spaces via the UI and via kubectl.

Space Templates

Loft allows users to define templates for namespaces, so that others can instantiate these templates to provision namespaces with batteries loaded. A template could pre-populate a namespace for certain use cases or with basic tooling required. Templates allow you to define Kubernetes manifests, Helm chart and more to be applied when the template is used to create a Space.

Loft even allows to parameterize these templates, so that template maintainers can define certain questions that Loft will show in form of UI forms or CLI prompts when a user instantiate a template. A parameter could be a picker for a certain version of a tool or a plaintext field for a name of a resource that is being instantiated. Some parameters may also be retrieved automatically via Loft’s API, e.g. the name of the user who is currently instantiating a template.

Virtual Kubernetes Clusters

Virtual clusters are fully functional Kubernetes clusters that run inside a single namespace of another Kubernetes cluster. Loft uses our open-source project vcluster to create virtual clusters. vcluster is a certified Kubernetes distribution which means that these virtual clusters behave 100% like regular clusters.

vcluster does not require giving users any additional privileged, i.e. users can spin up a virtual cluster and then feel like admins inside the virtual cluster but in the underlying cluster, they will still be restricted to a single namespace. Virtual clusters are incredibly lightweight and run inside a single pod. The workloads scheduled inside the virtual cluster will actually run in the underlying cluster, so there is no performance impact when working inside a virtual cluster.

5
Up to 1,000

= 10 x [User Limit]

The number of virtual clusters for your Loft instance is 10x your user limit, i.e. if you purchased Loft for 20 users, you will be able to create 200 virtual clusters. The virtual cluster limit is aggregated for the entire Loft instance and not enforced per user. You can additionally set up a limit per user as well but that would be your decision which does not impact pricing.

Unlimited
Self-Service Provisioning

With Loft, users can autonomously spin up virtual clusters whenever they need them. This is much cheaper than provisioning separate clusters because virtual clusters are very lightweight and can use shared resources from the underlying cluster if permitted (e.g. using the underlying cluster's shared ingress controller for all virtual clusters).

Additionally, Loft saves you cost with Sleep Mode (see below) because virtual clusters (just like Spaces) can be automatically put to sleep when not used for a certain period of time.

Virtual Cluster Templates

Loft allows users to define templates for virtual clusters, so that others can instantiate these templates to provision virtual clusters with batteries loaded. A template could pre-populate the vitual cluster for certain use cases or with basic tooling required. Templates allow you to define Kubernetes manifests, Helm chart and more to be applied when the template is used to create a virtual cluster.

Loft even allows to parameterize these templates, so that template maintainers can define certain questions that Loft will show in form of UI forms or CLI prompts when a user instantiate a template. A parameter could be a picker for a certain version of a tool or a plaintext field for a name of a resource that is being instantiated. Some parameters may also be retrieved automatically via Loft's API, e.g. the name of the user who is currently instantiating a template.

Cost Optimization
Basic
Cost Monitoring Per User/Team

Loft lets you deploy a Prometheus stack and customizable Grafana dashboard that show the resource consumption and cost estimates for every user and even for teams (typically mapping to SSO groups).

Quotas Per User/Team

Quotas in Loft let you define resource limits per user or per team. Quotas in Loft work just like ResourceQuotas in Kubernetes but instead of just allowing you to limit resources per namespace, quotas in Loft are aggregated across all namespaces of a user or a team, and they even work for virtual clusters.

Automatic Sleep Mode

Sleep mode puts namespaces and virtual clusters to sleep after a customizable period of inactivity. That means that you can configure that all workloads of a user will be turned off at night or over the weekend to save a substantial amount of cost for your Kubernetes clusters. If your clusters autoscale, you can typically save more than 70% of cloud computing cost with sleep mode. Sleep mode can be configured per user, per team or even per individual namespace.

Auto Wakeup: Sleep mode is 100% automatic and so is resuming from sleep. If an engineer runs a kubectl command against a sleeping namespace or virtual cluster, Loft halts the request for a second, restores the state of the sleeping namespace or virtual cluster, and then lets the request through. So, engineers don't have to do anything manually to profit from massive cost savings.

-
Auto-Delete

Instead of putting namespaces and virtual clusters to sleep, Loft can also provides an auto-delete functionality which uses the same inactivity detection logic and timeout triggering as sleep mode but instead of putting anything to sleep, Loft will delete the respective namespace or virtual cluster if auto-delete is configured.

Auto-delete and sleep mode may also be used in combination, e.g. sleep after 30 minutes and then auto-delete after 10 days of inactivity.

-
Beta

This feature is currently in beta and therefore, it may be offered free of charge. Beta features may become part of a certain pricing tier or they may be offered as add-ons once the beta phase will be over.

Sleep Mode Schedule

Besides inactivity detection, sleep mode, auto-delete and wakeup may also be configured using a static schedule. This schedule considers the timezone of the user who owns the affected namespace or virtual cluster.

Inactivity detection based and schedule based may be used in combination if needed, e.g. sleep after 30 minutes of inactivity and always at 10pm (of the user's local timezone), wakeup on new activity but also on Mo-Fri at 7.30am (pre-heat environment for the user to start working without waiting for wakeup in the morning).

-
App Store
Preview Only
On-Demand App Installs

Loft lets users define Apps that others can install into namespaces or virtual clusters. Apps are either a collection of Kubernetes manifests or a Helm chart with potentially pre-configured values.

Apps can be parameterized. If an app maintainer creates parameters, Loft may fill these parameters depending on the parameter specification which allow several options, including:

  • Asking the user for input (plaintext, selector/picker, etc.) via UI form or CLI prompts
  • Automatically retrieving values from Loft (e.g. name of the user who is currently instantiating the app)

Parameters can also be provided via a yaml file for non-interactive app instantiation in CI/CD, for example.

Apps in Space Templates

Apps can be selected to be part of a Space template for creating pre-populated namespaces.

Apps in Virtual Cluster Templates

Apps can be selected to be part of a Space template for creating pre-populated virtual clusters.

Admin & User-Defined Apps

Apps can be created by admins but (by default) Loft also allows non-admin users to create and share Apps. Who can create and modify apps (or certain specific apps) can be configured via RBAC.

Beta

This feature is currently in beta and therefore, it may be offered free of charge. Beta features may become part of a certain pricing tier or they may be offered as add-ons once the beta phase will be over.

Custom Install Parameters

Apps can be parameterized. If an app maintainer creates parameters, Loft may fill these parameters depending on the parameter specification which allow several options, including:

  • Asking the user for input (plaintext, selector/picker, etc.) via UI form or CLI prompts
  • Automatically retrieving values from Loft (e.g. name of the user who is currently instantiating the app)

Parameters can also be provided via a yaml file for non-interactive app instantiation in CI/CD, for example.

Secrets Management
Basic
Advanced
Shared Secrets

Loft allows users to store confidential information such as API keys or credentials in Kubernetes secrets that can be shared directly via Loft's UI, CLI but also via kubectl.

Loft shared secrets can be retrieved via Loft CLI, kubectl and as auto-populated Kubernetes secrets.

Fine-Granular Permissions

Maintainers of shared secrets can configure who can read, update or delete them. Admins can also configure who may create shared secrets in the first place.

CLI-Based Retrieval

Loft CLI provides the command `loft get secret [name]` to retrieve the value of a secret via CLI. This is often useful to integrate the shared secrets in development tools such as DevSpace or to consume them within CI/CD pipelines.

Beta

This feature is currently in beta and therefore, it may be offered free of charge. Beta features may become part of a certain pricing tier or they may be offered as add-ons once the beta phase will be over.

Auto-Retrieval ForNamespaces

Shared secrets can be used to auto-populate Kubernetes secrets. If a user creates a Kubernetes secret with a certain annotation referencing the name of a shared secret, Loft will automatically update the `data` of this Kubernetes secret with the content of the shared secret. Loft will also keep these Kubernetes secrets updated when the shared secret changes which makes API key rotation and similar tasks very easy without disrupting the engineers' workflow and without the need to share secrets via email or Slack.

Preview Only
Beta

This feature is currently in beta and therefore, it may be offered free of charge. Beta features may become part of a certain pricing tier or they may be offered as add-ons once the beta phase will be over.

Automatic Updates (Sync)

Loft will keep Kubernetes secrets that use the data of shared secrets updated whenever the shared secret changes. This makes API key rotation and similar tasks very easy without disrupting the engineers' workflow and without the need to share secrets via email or Slack.

Preview Only
Secrets Encryption

Loft can encrypt shared secrets by default so that only users with read permission to the shared secret can access it via the Loft API, UI or CLI. The underlying Kubernetes secrets will not contain the usual base64 encoded data but instead a base64 encoded string containing the encrypted data, so if someone has direct access to the underlying Kubernetes secrets, they will still not able to directly read the data of the secret.

-
Paid Add-On
Auditing & Advanced User Controls
-
Optional
Audit Logging

Loft's audit logging feature logs all interactions of users with their connected clusters, namespaces and virtual clusters. That means that you can replay sessions and review any kubectl commands that a user executed, etc.

-
Paid Add-On
User Locking

Loft allows admins to lock/disable users. These users cannot log in anymore and will not be able to use their spaces or virtual clusters any longer. Disabling a user is a security feature but also has a cost benefit since disabled users do not lose any data but they will not count towards the user limit anymore.

-
-
Enterprise-Grade Deployment
-
Optional
High Availability Mode

Loft provides high availability for all components in the Loft management cluster as well as in all connected clusters. High availability is achieved via replication for stateless components and via leader election (with warm standby) for state-manageing components (controllers).

-
Paid Add-On
Direct Cluster Endpoints

If you are working in a geographically distributed team, users will likely work in separate clusters that are located relatively close to their phyical location. This prevents roundtrips of requests across the globe. Typically, Loft acts as an API gateway which means that all requests to any connected cluster go through Loft's API first. However, if Loft itself is running in a cluster in North America but a user is based in India and wants to work with a connected cluster in Asia, every request would first go from India to North America and then would be routed back to Asia. This introduced additional latency.

To reduce latency, Loft provides a distributed mode called "Direct Cluster Endpoint" which replicates the necessary access control data from the main Loft cluster to the respective connected clusters, so that users will be able to directly connect to the connected clusters without an additional rountrip to the Loft management cluster first.

-
-
Air-Gapped & VPC Clusters

Loft can be installed using an offline license key. This means that the Loft instance does not need to verify the license key with our license servers which means that Loft can be installed to Virtual Private Clouds and fully air-gapped data centers.

-
-
Support & Customer Success
Basic
Standard
Above + Beyond
E-Mail & Chat Support
Support via Slack or MS Teams

We provide a public Slack channel via slack.loft.sh

For enterprise customers, we also offer to set up a shared Slack or Microsoft Teams channel that will not be publicly accessible. Only members of your organization will be able to join this channel to receive direct support from our engineers.

Public Channel
Public Channel
Private Channel
White Glove Onboarding

Our white glove onboarding supports you in finding the perfect configuration for Loft, provides hands-on assistance when deploying Loft to your clusters and connecting your SSO provider, as well as during the rollout of Loft to your engineering teams.

-
Paid Add-On
Customer Success Team

Our customer success team is a constant point of contact for you that will help you after the initial setup. We are very quick to respond to feature requests and bug reports, and our team is committed to ensure that you are getting the most out of Loft for your current and any future use cases that Loft may be used for in your organization.

-
-
Custom SLA

We can provide custom services level agreements for high-volume customers. Please contact us via sales@loft.sh if you are interested in a custom SLA.

-
-
Upon Request

Productive

Buy Now

Enterprise

Contact Sales

Frequently Asked Questions

Do you offer free trials?
What are Virtual Clusters?
Does Loft provide SSO via Okta, SAML, OIDC, LDAP, etc?
Do you support pay by invoice?
Can I get a custom quote?
Do you have a startup discount?
Can we change the number of users during an annual subscription?