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.
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.
Loft provides integrations for all major single sign-on providers, including:
You can even connect multiple authentication providers in Loft and let users choose how they want to sign in.
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.
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.
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.
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:
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.
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.
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.
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 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.
= 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.
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.
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.
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 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.
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.
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.
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.
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).
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:
Parameters can also be provided via a yaml file for non-interactive app instantiation in CI/CD, for example.
Apps can be selected to be part of a Space template for creating pre-populated namespaces.
Apps can be selected to be part of a Space template for creating pre-populated virtual clusters.
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.
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.
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:
Parameters can also be provided via a yaml file for non-interactive app instantiation in CI/CD, for example.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
