Cloning public repos
Clone public repos without needing to add SSH keys. You still need to configure ssh for private repos.
Add Git URLs to existing dev environments
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.
Redesign: Introducing Environments
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.
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.
Git Repositories
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).
Install Scripts
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!
Environment Variables & Secrets
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 ❤️
Upgraded Autostop
We made our workspace autostop far more reliable
This can save money for every engineer that is doing remote development regardless of where your instances are deployed. We are able to detect SSH traffic to the instance and stop that instance within 3 hours of inactivity.
Error messaging on console
All error messages from our server are shown on the console and made more comprehensible. It is also possible to access the complete error log in your chrome devtools console.
Join Workspaces without Git Repositories
Brev now lets users clone the workspaces of their teammates — even if the workspace does not have an associated git repository.
List workspace breadcrumbs
brev ls was printing all possible SSH commands previously that made it harder to navigate our CLI — we consolidated that into a more cohesive readable format that makes most sense to new users.
Faster Login Page
Now you can run brev login --skip-browser to allow login without having to hit enter
Workspace Scope Environment Variables
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.
Github SSH Key Integration
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.
Reset Multiple Workspaces
You can now pass in multiple arguments to this command: brev reset <ws_name>…
This also works with the —hard flag too.
Reset Breadcrumbs
We now very clearly indicate when you need to reset your workspace. We show you breadcrumbs when a workspace is in an unhealthy or failed state and point you to the commands that will fix it.
SSH Wrapper: Get a Terminal for any Workspace
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.
Performance
We’ve added a Redis cache to our backend for improved performance. This has reduced our read usage for DynamoDB (by around 32 - 51%).
Stop Multiple Workspaces
You can now pass in multiple arguments to this command: brev stop <ws_name>...
Setup scripts (without committing to your repository)
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:
VSCode extensions persist on brev reset
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.
Auto-install your VSCode extensions
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.
New Options for Personal Configuration
Import your personal shell settings, aliases, etc to all of your workspaces by going to console.brev.dev/profile and adding a custom repository + path to the execution script.
If you don’t have one, we have a starter that you can use at github.com/brevdev/user-dotbrev
Stop all Workspaces
Run brev stop --all to power down all of your workspaces.
Performance
We launched a new workspace cluster. This has created massive improvements in stability and speed.
New Command: brev shell workspace_name
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.
New Command: brev reset --hard 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.
Clearer Error Handling
We now have clearer error messaging (rather than a stack trace). We have a verbose mode which shows you where the error is happening in our codebase that you can turn on in your ~/.brev/config.yaml file by adding feature.debug = true.
Clearer Command Messaging for brev login and brev start
brev login: we now tell you the org that you’re in and that you should type in brev ls to view the workspaces in the organization. We also show you how to change orgs.
brev start: we now tell you that you can type in brev open or brev shell to enter your project. brev open will use your preferred editor and auto-connect you to the machine. brev shell will ssh you into the machine.
Sanitized Workspace & Organization Names
We now coerce and sanitize organization and workspace names to be subdomain compatible. This allows us to do interesting things in the future with routing, invite links and anything involving a URL!
Workspace Setup Infrastructure: V2
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).
Share a Workspace
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:
We accept repo (git repo url), name, size (type WorkspaceClass) and setup (setup script url).
Onboarding
This is now duplicated and synced between the CLI and the web console. You can start the onboarding process and pick up where you left off on either.
Faster and more resilient data storage
We use DynamoDB to hold user information and metadata surrounding workspaces. We just enabled multi-leader cross region replicas, meaning we now have replicas of our data that are sync’d across all AWS regions.
Performance Fixes
brev ls is now running 40% faster. Added global secondary indices to DynamoDB and replicated our data to live in us-west-2.
Import Existing Projects
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.
Deploy in your Cloud
We now support this for select enterprise customers.
Invite Links are on the Web Console
Invite Links Last 7 Days
This used be 24 hours but that was too short notice for users who wanted to join.
Improved Error Logging for Setup Scripts
We added Sentry to log setup script failures. This will give us visibility to patch common bugs.
Multiple Arguments for brev delete
brev delete now takes multiple arguments. As we continue with a full CLI review, we’ll add this to more commands.
Invite Links
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.
Automatic Development Environment Creation
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.
Multicluster Support
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.
Homebrew Installed by Default
This means you can just type in brew install python@3.5 to install Python 3.5. Note that we still recommend you use Linux scripts rather than brew to install as it is significantly faster and we cannot guarantee compatibility for all libraries.
Start Workspaces with Custom Environment Script
You can now run brev start git_repo --setup-script gist_url which takes in a gist or pastebin url to a custom setup script (be sure to use the 'raw' text file link). This way you can create an environment before even starting a workspace.
CLI Authentication on Remote Workspace
The CLI is automatically installed on each of your workspaces. We now also auto-log you in so you can just run brev ls or any other commands without having to re-login.