By default, your Cages can be run by any client with a valid API key, but you may want to have additional control over where your Cage can be run from.
You can now restrict your Cage to only accept invocations from a predefined set of IPs. Define a list of IP addresses and/or CIDR blocks to accept in the Evervault dashboard.
If a Cage run is requested from outside of your whitelist, the invocation will be rejected with a status code of 403, or a ForbiddenIPError in our Node & Python clients.
You can read more about Cage IP whitelisting in our docs & can get started by going to Dashboard → Cage → IP Whitelist.
Outbound Relay traffic passes through Evervault’s proxy and is decrypted before going to trusted destinations like Stripe or Twilio. We’ve added the ability to put a hard constraint on what destinations data should be forwarded to.
When you start configuring Outbound Destinations for a team, any request to a domain not in the list will be blocked whether it contains encrypted data or not.
You can now start restricting your Outbound Destinations in the Evervault Dashboard: Settings → Outbound Destinations → Configure Destinations
Environment variables are helpful when storing strings such as node environments and API URLs. But, it can also contain values best kept secret like database passwords.
We just released new functionality that allows you to securely store secret environment variables. You can now choose to make your environment variables secret at creation.
By choosing this new option, your environment variables will be masked in the Evervault dashboard and CLI.
You can access the feature in the Evervault Dashboard: Cage → Environment Variables → Create variable
We know that latency is a core consideration when implementing Evervault Relay, so we’re delighted to be releasing our new latency reporting functionality today.
For every request your users send through Relay, we measure and record the latency between Evervault’s infrastructure and your infrastructure. The charting functionality in the Dashboard allows you to analyze latency at various percentiles, making it easier for you to make latency commitments to your own users.
Application performance is a major priority for us in every engineering decision that we make, so we’re excited about this first step in holding ourselves accountable for improving your infrastructure’s performance.
We are happy to announce charting for Relay requests. The goal is to help make traffic data more digestible, so it’s easier to monitor trends over time, see spikes in traffic, and identify any possible bottlenecks.
With the new charting capabilities, users are also able to filter by HTTP code (e.g. 2XX, 3XX, 4XX, 5XX) or any search term — because when you filter for logs the chart is also updated to reflect your search.
This is the first of a series of improvements we are making to help users better understand traffic behaviour, and get better insights from their data. Stay tuned!
This month, we overhauled the Evervault documentation. We rewrote and reprioritised content, improved navigation and discoverability and reworked the landing page. Overall, it’s a big plus for developer experience. Within the coming months, we’ll also be adding technology-specific user guides to cater to the growing number of Evervault use cases; so keep an eye out for your stack.
Check out the new and improved Evervault documentation at docs.evervault.com.
Evervault Relay accepts connections from your users, encrypts sensitive data fields and then connects to your API and transmits the encrypted data over TLS. Occasionally, errors can occur between your user and Relay or between Relay and your API. These errors can often be difficult to debug without verbose request logs.
We just released new functionality that surfaces underlying system errors to developers, so you can quickly identify issues in your system. The errors displayed are bubbled up directly from our underlying HTTPS implementation and include details on things like TLS handshake errors, socket hangups and network timeouts.
You can access the feature by navigating to Relay → Activity Logs in the Evervault Dashboard.
Coming soon: get notified about unusual events and error spikes by e-mail, SMS, PagerDuty or Slack.
Evervault Relay communicates directly with your API over Transport Layer Security (TLS). Your API may be configured to require client-side TLS authentication. This is known as Mutual TLS (or mTLS).
We just released a new feature that allows you to upload an mTLS certificate to authenticate the connection between Relay and your API.
We also allow you to upload password-protected certificates for added security.
Enabling mTLS between Relay and your API means that you can block any requests that are not routed through Evervault, preventing you from accidentally collecting plaintext sensitive data as well as giving you the ability to reject clients that are not protected by Relay's network-level security capabilities.
You can access the feature by navigating to Relay → Configuration → Mutual TLS Certificates in the Evervault Dashboard.