Last week’s redesign made it easier to navigate the Brev console and create new dev environments, however, it wasn’t possible to add git repos to existing dev environments.

This week’s update to the console lets you modify or add new Git URLs by clicking on the name of your created environment. This supports workflows such as starting from an empty dev environment and building it out as you go.

For the last 3 weeks, we’ve been working on a way to make all of our capabilities more discoverable. After numerous customer conversations, we decided to re-design our console UI and the language around the concept of an environment.

‍

‍

We offer a way for engineers to pre-configure and share environments.

We previously used the concept of a “workspace”, which was confusing to most users. We now abstract the idea of where the environment runs as a configuration detail when setting up your environment.

‍

Create New Environment Page

This starts with a new ‘Create’ page with expanded configuration options for your environment. This includes Repositories, Install Scripts, Environment Variables & Secrets, IDE Configuration, Machine, and Name cards.

We now support multiple git repositories in your environment. If you select multiple, you can choose the working directory for your workspace to open when connecting to it (either through SSH, or your local editor).

Our environments emulate an Ubuntu 20.04.4 LTS operating system with a base docker image that has standard tooling and Linux essentials.

From there you can install any software that is needed to develop your code. You can execute those scripts from a repository or by copying an existing bash script.

We find that usually, clients have encoded their production environments in a Dockerfile or bash script. As your production environment is usually a subset of your development environment, you can easily use those scripts to get started!

You can now add environment variables and secrets that apply by scope (either to this environment in particular, all environments, in your organization, or for environments that your user has created).

‍

‍

There’s plenty more in our redesign that included slight changes to other pages in our frontend.

In the coming weeks, we will release patches as we find them, as well as update other portions of our codebase to reflect this shift in thinking (including our CLI, landing page, and other pages in our console).

Please give us feedback in our Discord here! Any and every piece of feedback is appreciated ❤️

You can now add secure environment variables to your workspace. You can also use this to add constants.

We already support organization and personal environment variables on the account and organization settings page. All secrets are encrypted at rest and stored using Hashicorp Vault.

We now make it easier to add your SSH key to Github. When onboarding, we ask for permission issues to issue you an SSH keys that allows you to securely clone Github repositories into your container. We previously had you copy the SSH key and put it in your account.

All private keys are encrypted at rest and securely stored in our enterprise secrets manager.

We hate having to manually enter and update ssh config. So to connect to your workspace automatically, we’ve created a wrapper command This is a shortcut to ssh into your workspace. Just run brev shell <workspace_name> to open a terminal into your workspace.

Brev.dev works best when a setup script is saved, which creates the reproducible & sharable environment. You used to be required to commit this setup script to your repo at a specific file path .brev/setup.sh, however you can now use any file path and can reference an external repository. Here are your options:

• Custom Path in your Repository: Supply a path when creating a workspace to use the setup script of your choice if committing to the repo.
• External Repo with Custom Path: Optionally choose an external repo for your setup script. This will allow you to save your setup scripts separate to your code. The setup script repo can even be private.
• File Upload: You can also copy and paste an existing shell script by entering the text directly.

We used to persist all files in /home/brev/workspace on reset. We now persist the entire volume at /home/brev, so VSCode extensions and terminal settings persist.

Run brev import-vscode-extensions (or brev login) to save your VSCode extensions to your profile. Brev.dev will automatically install them for you on every workspace you create.

Save any of these extensions as part of a “workspace template” for new contributors.

This is the same as running ssh workspace_slug but now you don’t have to remember the slug. You can directly use the workspace name.

Deletes and recreates a workspace in one go. This deletes the entire machine without preserving the file state, and re-creates the workspace as if it were new (re-cloning the repository if you have one). If you have not committed your files you will lose it running this command.

Note: the normal brev reset workspace_name preserves files in /home/brev/workspace (this includes your .zshrc and .bashrc ) and gives you a new machine.

A number of internal changes were made to improve the way we startup workspaces. Previously, we used the Kubernetes PostStart container lifecycle hook to execute setup commands as well as your .brev/setup.sh script. Now, we install a custom binary on the remote machine and use systemd to execute certain commands.

The main benefit from this change: installing dependencies is no longer synchronous and therefore blocking. You can open your workspace sooner, while we are running the install commands. This makes startup times much faster. You can now watch your dependencies install by going to .brev/logs/setup.log

We also now allow you to create a workspace to a branch, tag or commit (rather than just to main).

This also gives us more visibility into your machine. We can now build features like sending you logs while the machine is being provisioned, or push updates remotely to this infrastructure (we can tell you to run brev reset and our updates will apply).

You can now share you workspace with another user. We will expose it publicly soon but as of current you can share by entering the following:

• https://console.brev.dev/create?key=value

We accept repo (git repo url), name, size (type WorkspaceClass) and setup (setup script url).

Type in brev import . in any local folder and we’ll automatically create a workspace for you. If you don’t have a setup script, we’ll automatically generate one for you.

We now support this for select enterprise customers.

Type in brev invite and we’ll automatically give you an invite link you can share with users. It will add them to your organization so they can join existing projects.

When you start a workspace, we will automatically detect your dependencies and create a setup script. This will form the basis of your setup script that pre-configures your environment. We currently support Node, Golang, Gastby and Rust.

For increased security for our enterprise clients, we now have dedicated infrastructure for your workspaces that sits in a separate cluster from other workspaces. This is a pre-step in creating deploy in your own cloud.