Previously, an application had pages but nothing to tie those pages together. This made it difficult for a new user to navigate. They didn't have a clear path to discover their application. There was a need to let users step back and view their whole application at a high level.
The Application Dashboard is your application's landing page. On this page, you have quick links to the major Application pages that you are already familiar with, an assortment of widgets, and an activity feed.
The Widgets show you your environments--how many you have, their types, and their statuses. The Activity Feed shows the application's builds and deploys and the current status of those. Both the widgets and the activity feed are updated in real-time to reflect the current status of your application.
We will continue to monitor, adapt, and grow this page.
It is not unusual to have a large amount of wildcards you might want to support for your website. This could be subdomains to support your production-like routing, or could support use cases only for testing before production. For example, you might want to use a country-code subdomain for specific languages supported on your site:
Or, you might have a long laundry list of categories that your site supports for SEO and you want to verify all the links work before production is hit:
Lastly, you might have subdomains that you customise for customers, employees, or other tenants on your own custom self-hosted domains:
In the above cases, if there are only one or two subdomains, you could easily list them one by one in your application configuration. But if the number of subdomains is not known in advance, or can change and grow over time, or if there are simply too many of them to manage manually, you can now create a wildcard subdomain that will be routed automatically to your dynamic or static site, no matter what subdomain is used.
The best part is that we manage all the DNS, routing configurations, SSL certificates, and deployment complexity in real-time for you so your use case just works!
Although the routing configuration works and customers are using it, this is a new feature so we're still working on improving the ergonomics of the configuration interface. If you need this feature or want to see it in action for now, please reach out to us to get it setup and tested. We'll add it to the documentation once it's fully vetted.
Just-in-time File Mounts
Just-in-time File Mounts allow you to mount a file within a container at a specified mount point when your container is created. This allows you to have configuration files that you don't check-in to your source control repository that are accessible to your services. A good use case for this helpful is when you have secrets stored in a file that you'd rather not checkin to your repository (and if you're doing this, stop!). When you check the 'secret' box within the Just-in-time File Mounts dialog, that tells Release to encrypt and store the file securely.
You can find Just-in-time file mounts in your App Settings and in the Advanced section when you create a new application.
Customer account management
As an account owner, you can switch your fellow team member's role from "member" to "owner" which allows more permission levels such as editing the Application Template.
Fixed a bug in static builds where an S3 path with a plus sign ("+") would be interpreted as a space by the browsers. If you do notice any issues with strange characters or symbols in a path, try to avoid using them and also let us know so we can try to deal with them.
Secondary email addresses for Github are now supported. If you logged in with your non-primary email address, Release wouldn't validate your email and now we do!
It's been awhile since we announced what's new on Release, but that's not because we haven't been heads down working on improvements. In fact this week we released a major overhaul of the experience that changes some of the fundamentals that we've realized were important as we've worked with many of our customers. This update will be longer than most but it's worth the read!
Release manages all aspects of building, deploying, updating DNS, Cloudfront and connecting frontend apps to the rest of the services within their environment.
We've made major changes to creating application in Release to make creating complex applications dead simple. Take a read through our Static Service Deployment reference for more information.
Every environment in Release is derived from the Application Template. The Application Template is a YAML description of services, hostnames, networking, environments. This template is what all created environments are derived from and is their starting point. All new environments use this template and pull their initial settings from here. In this update, the Application Template has been enhanced with a ton of new capabilities.
We've also added modifiable Environment Configurations. This allows you to modify an instantiated environment beyond its initial settings inherited from the Application Template.
This was a major change in the system, prior to this update there was no way to modify a running environment's configuration without updating the Application Template. This was a big limitation that made it impossible to change a running environment without impacting other running environments. Any change to the template was immediately applied to subsequent deployments of other environments which made experimenting with an environment impossible. If you're interested, read through our Environment Settings reference to dig deep!
With Application Templates and modifiable Environment Configurations Release environments are infinitely flexible and approachable. Feel free to tinker and experiment with your environments.