Delivery FAQs

Overview

Release powers the deployment of environments as a service (EaaS) for customers who want to be able to quickly and easily spin up entire application stacks for development, testing, QA, staging, user acceptance testing (UAT), sales demo environments, or production, to name a few of the possible use cases.

Release Private Applications are a unique and modern way for software-as-a-service (SaaS) providers to deploy their products into their customers' cloud accounts for a fully private, single-tenant version of the SaaS provider's platform.

Delivery FAQ

Q: What is software as a service (SaaS)?

SaaS means that a software provider can deliver its product as a service over the internet, rather than as software that the customer needs to install on a computer or server.

The software provider typically deploys this software in a multi-tenanted environment, that is, it usually supports many customers in one deployment or environment stack that is served over the internet.

Q: What is environments as a service (EaaS)?

Environments as a service is the unique and modern Release product offering that customers (in the case of Private Application customers, typically SaaS providers) can use to deploy multiple environments for any use case imaginable.

Q: Tell me a story about software releases?

Long, long ago, before there was an internet, software companies would develop software and then bundle it on physical floppies, CD-ROMs, and even DVDs that customers would physically insert into their computers and then run an installer to use the application software. Typically, there were two versions of the software: a client and a server. As the internet became ubiquitous, most software delivery mechanisms were given to end users via a download package rather than on physical media, but this still required an end user to install the software and configure it in their environment. Most modern software today is delivered as a service so that the "client" is often just a web browser or mobile device and app, and the "server" runs in the control of the software provider rather than the customer. The Release EaaS offering is basically a "SaaS installer" that allows the delivery of private applications into the private cloud accounts of the end customers, starting the next revolution of internet software delivery platforms. This means that a customer could install a private version of a SaaS application under their own control, in their own cloud account.

Q: Why does a SaaS provider or their customer need to use Release at all?

If you are a SaaS provider, you need to think about how to deliver your platform software into a customer's control in a way that is seamless, reliable, and simple to maintain and update. If you are a SaaS customer who wants a single-tenant solution that is deployed in your own cloud account for your own use, you want the same ease of installation and updating of a SaaS offering over the internet, except private and not commingled with other SaaS customers. Release powers this by giving a SaaS provider the ability to deploy a private application as an environment directly into their customer's cloud account in the same way they would deploy their SaaS offering internally for development and testing, externally in production, or privately into their customer's single-tenant experience. As a SaaS provider, you may want access to your customer's private cloud services or data so that you can offer a tailor-made solution for data that the customer would not want to share remotely or would be unable to share due to compliance or security considerations. As a SaaS customer, you may similarly be uneasy (or even unable) to use a SaaS product unless you can ensure that your data and private services are kept completely private and within your control.

Q: What are the security implications of Release-hosted Private Applications?

Release deploys EaaS via a cloud integration, which is a set of credentials for AWS, AWS GovCloud, or GCP that the end customer associates with the SaaS provider's application deployment. Release uses these credentials to build, deploy, and update the infrastructure and codebase for the SaaS provider's private application. The result is that Release needs permissions to build infrastructure, update code, and so forth in the customers' cloud accounts. A detailed list of permissions can be provided in detailed documentation, either directly or as a white-labeled document by the SaaS provider.

Q: How can I trust Release's and my SaaS provider's security postures?

Rest assured that Release can provide a SOC 2 report for commercial accounts and is willing to sign a BSA with HIPAA providers. This should give you comfort that Release's security posture meets or exceeds industry standards and that Release is confident that its systems are reliable and secure. Your SaaS provider can give you all the information regarding their security stance and posture as requested.

Q: Can I just take a bundle of software and install it myself from the SaaS provider?

Currently, Release-hosted Private Applications install in an unattended process that bundles and deploys software without intervention. There is no current offering to bundle and offline-install the private application, although Release is considering many options for features like this in the future.

Q: What are the best strategies for keeping my cloud account secure for Private Applications?

Customers accepting a Release-hosted Private Application in their cloud accounts should follow current best practices:

• Use a specific, empty subaccount (AWS, AWS GovCloud) or subproject (GCP) in your organization that is isolated and does not have any private or secure data you do not mind sharing with the SaaS provider.

• Enable strict auditing and controls on the credentials (the "IAM integration role" in AWS and AWS GovCloud, "project permissions" in GCP) that you provide to Release for the cloud integration.

• Only allow specific applications access to your databases, internal services, or storage objects. For example, for AWS and AWS GovCloud customers, use AWS VPC peering, AWS security groups, AWS IAM policies, and/or AWS PrivateLink to limit access to sensitive resources. For GCP customers, limit access between private projects and folders within the organization so that access between the Release-hosted Private Application and sensitive data or systems is limited only to the specific access that is required.

• Consider any open-source or third-party security monitoring products to alert and audit access controls made via the AWS role or the GCP project as an ongoing mitigation against unauthorized access.

• Consider disconnecting the AWS role or GCP project credentials after the initial installation and between updates to limit any unauthorized access in between product updates. Your SaaS provider will need to schedule a manual intervention to allow you to re-engage the permissions so that the private application can be updated. Ask your SaaS provider for details on this option.