Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Schedule ECS tasks locally using ecs-cli
Create a new workspace with Docker installed ().
Go to AWS Console > IAM > Users > Create user.
Add the following permissions to the user: AmazonECS_FullAccess.
Obtain the credentials under Users > id > Security credentials > Access keys > Create access key.
Install the ECS CLI:
Set the correct permissions:
Configure the default profile:
Configure the default cluster:
Download a task definition:
Bring up the containers:
Recipe specifications are YAML-based definitions that outline the resources, infrastructure, and configuration of a DevZero workspace. These specifications are centrally stored and version-controlled by DevZero, ensuring your team always has access to the most up-to-date and consistent environments.
Key features of recipe specifications:
Shared via Recipe Library: Team members can access and use recipes through a centralized Recipe Library (My Recipes).
Consistent Environments: Ensures all team members use identical, up-to-date development and testing environments.
Golden Path Definition: Typically defines the optimal setup for developing and testing specific applications or microservices.
Version Control: Allows tracking of changes and rollbacks if needed.
Resource Management: Specifies all necessary resources and infrastructure for a workspace.
By utilizing recipe specifications, teams can streamline their development process, reduce environment-related issues, and maintain consistency across different projects and team members.
Custom base images are only support for our Enterprise customers. If you need a custom base image, please reach out to your support contact at DevZero.
DevZero currently uses ubuntu:22.04
as the base OS for all recipe builds. We anticipate releasing custom base images to all users sometime later this year.
DevZero is a cloud development platform designed to help software engineers spend more time writing code and less time waiting on builds, troubleshooting dev environments, and fighting over shared resources.
With the DevZero platform, you can centrally define and manage cloud environment specifications for development, testing, CI, and more. This ensures that developer environments are always consistent, up-to-date, and secure.
Developers can use these specifications alongside our CLI to launch their own ephemeral, namespaced, and extensible cloud environments. Developers can connect using any IDE of their choice or leverage a browser-based IDE/shell. We automatically take care of all the ergonomics, too, like shell config, dotfiles, and more, to ensure things match your preferences.
If you're ready to get hands-on, we recommend diving into the Quickstart guide. However, if you'd like to read a bit more, you can check out the Terminology reference sheet. You're also welcome to chat with us directly, the best way to get in touch is to email support@devzero.io.
Visit our dashboard (devzero.io/dashboard) to create your free account and install our CLI. Then head to the Quickstart section of our docs.
More on this in Terminology > Kubernetes Cluster
The quickstart covers these steps as well.
Learn how to get up and running on the DevZero platform.
New to the platform? We recommend getting started with our Platform Overview and then running through the Quickstart example.
Use your existing tech stack, databases, services, and more by following our setup guides.
The repos block of our recipe specification is used to clone code. This will use the permissions of the GitHub application you have connected with DevZero.
To clone one or multiple repos:
Estimated time to complete: ~5 mins
Welcome!
Follow the steps below to get started on the DevZero platform. Or, if you're more of a visual learner, we have a video tutorial as well!
You'll need to sign up for a DevZero account before you're able to do anything. We require you to have an existing account with an external Identity Provider (such as GitHub, Microsoft, or Google). To sign up for a DevZero account & create your DevZero team, please visit https://devzero.io/dashboard
You can connect your source code provider during the workspace creation or though the "User Settings"
We currently only offer native support for GitHub as a code provider for DevZero's workspaces. Bitbucket and GitLab support are coming soon!
If you only plan to work with public repositories, you do not need to enable our GitHub integration. However, if you'd like to work with private codebases, you'll need to head to https://www.devzero.io/dashboard/settings/user-settings and complete the installation and authorization steps.
For more information (including a hack to use Bitbucket and GitLab repos), see our Source Code in Recipes guide.
Great! Now, you'll need a recipe to build your first workspace. A recipe is a blueprint for your environment. DevZero uses these recipes to provision your workspaces -- for example, cloning from a Git repository, installing dependencies, or importing your dotfiles.
We currently only support creating recipes via our Web UI (https://devzero.io/dashboard), so you'll need to head there to get started. Once you're there, you should see a button on the top-right corner, labeled "Create New".
When you click that button, a menu should pop up with two options. We want to create a new recipe, so click "Create New Recipe".
Once you click that button, you should be taken to a new screen. This is where the magic happens.
In that text box, you can put any Git repositories, public ones or ones you have access to, and, using some clever DevZero magic, we'll detect the programming languages, frameworks, and dependencies that are needed for that repository. We'll also generate a starter recipe with all of those things preloaded. Cool, right?
Make sure to "Add" each repo that you would like to include in your environment.
For the sake of this tutorial, let's use a personal website repository (https://github.com/hatf0/hat.fo-next). This is a Next.js / Tailwind CSS app built on top of Node.js, which we happily support.
Click the 'Next' button, and sit tight while we craft your starter recipe!
After a few moments, you should be redirected to our recipe editor page. We've finished doing our checks on your repo, and now you're ready to start further customizing your recipe. We support two ways of building recipes - the visual editor, or the text editor. To see the raw recipe, click the "View YAML" switch at the top right.
Review the recipe we generated, and if everything looks good, click the "Save" button at the top-right of the page. A modal should pop up, asking you to name the newly generated recipe. Don't worry -- you can always change this later. Let's keep things simple, and call it "My First Recipe".
Once you're done naming the recipe (we know, naming things is the hardest part of any software engineer's job), click the "Save" button at the bottom-right of the modal. You'll be redirected to the next page, where we'll attempt to build your recipe. These builds are similar to a base-image for any workspace that is launched from the recipe specification. We do a lot of clever caching to keep things snappy and prevent needing to rebuild everything each time you launch a workspace.
If your build is successful, a button near the top-right side of your browser should appear, allowing you to "Launch Workspace Now". Great! Clicking that will deploy a workspace from the build image we just created.
Click the "Launch Workspace Now" button, and you'll be whisked off to your workspace's page! What's happening here? During this stage, we are initializing a cluster for your user (if one doesn't already exist), deploying the workspace into that cluster, and setting up all of the fun networking bits.
The DevZero CLI, or dz
for short, is the primary interface for connecting to your workspaces. We've built a simple "one-click" installer script that installs the CLI & prepares you to connect to a workspace. To use the installer, in a terminal window, run the following command:
Please be sure to run these two commands after the installer finishes:
Once ready, a button should appear at the top-right, labeled "Connect". Click that drop-down, and you should be presented with three tabs:
Click the "Terminal" tab, and then copy the command at the bottom of the drop-down. Open a new terminal window, paste that command, and you're in! Congratulations, and welcome to the DevZero platform!
If you face any issues, please send an email to support@devzero.io, or visit https://devzero.io/dashboardand click the "chat" icon in the bottom right-hand side of your browser window. We'd be happy to assist you.
From your , select Create New
>> Create new recipe
. This will take you to the page.
Provide a name for your new Recipe.
From here, you can choose to use a public Github repository by providing a URL or you can authenticate to our Github App to select a private repository.
Alternatively, you can launch a blank Recipe by clicking "Create a recipe" without providing a code repo.
Make desired changes to your Recipe, select 'Save and Build' to initiate a build process, verifying successful Recipe compilation. To streamline Recipe creation, we offer suggested steps based on an analysis of your code.
After you've successfully built your Recipe and are done iterating, you're ready to Publish the Recipe to your Recipe Library.
We provide detailed build logs to help you identify any errors in your build and make iterating on Recipes easy.
If you don't have any recipes yet, please follow the "" guide first.
Visit DevZero Web console > Recipes. You should be able to see recipes published by your teammates.
Open the menu by pressing the 3 dots icon on the recipe you want to share.
Click on Copy Link to share the recipe source code with your colleagues.
For documentation on legacy recipe syntaxes (i.e. v1 and v2, please reach out to support@devzero.io)
A recipe is a definition of a workspace. It consists of a base workspace configuration, and a set of steps to be executed. Let's look at a simple recipe:
Steps while optional are the core tool that you will use to configure your workspace and prepare it for work. Steps can be executed either during . This is accomplished by placing the steps in the corresponding section:
The file hello_launch
will get created during your workspace startup, while the file hello
will be created at build time.
You can most step you want between launch and build phases of the recipe. But keep in mind that doing more work during the launch of the container will make your workspace start slower.
At the moment we have following step types available:
The bread and butter step, pretty much everything you need can be accomplished using this step.
You can have multiline commands, for example:
Creates a file with some content.
Paths are not using shell expansion, so you have to write out /home/devzero/projects rather than ~/projects
Creates a directory.
Same as with files path is not expanded, so ~ and environment variables will not be replaced with corresponding values
Installs apt packages.
We also support an easy way to add extra repositories, for example:
Or:
Clones a git repository.
System secrets are in the namespace devzero
currently only one such secret exists devzero.GITHUB_ACCESS_TOKEN
this token is populated using github account information for the user who is invoking the build
If you want to set a particular environment variable to some value you have to do it for each phase separatly. Phases being build
, launch
and runtime
.
Build time secrets can only come from team secrets or system (devzero) secrets. These environment variables will be available to any command executed within build phase, any values that make it into the final image will be part of it and will be available to anyone who launches the workspace.
Launch time secrets can be sourced from both team and user secrets. These environment variables will be available to launch commands defined in the recipe. This does not include systemd units defined outside of the recipe (for example if you install docker or mysql, environment variables defined here will not be visible to startup scripts for these tools).
Runtime environment variables will be present in any session (ssh, vscode, vscode terminal) started on the workspace.
Runtime environment variable customization is a bit special in that it supports Shell expansion (as opposed to build and launch environment variable settings). This is so you could configure development environment for your engineers more easily.
You can provide environment variables to a single command only. The syntax for the variable is the same as for global ones for example:
The variable can come from both - the recipe or secrets registry.
At the moment build time and launch time repository access can be controlled either automatically by using associated Github access credentials, or can be customized on a per step / per recipe basis. If you don't do any customization of the recipe, personal Github credentials for the user who triggered the build will be used during build time. But if the git-clone step is part of the recipe launch phase, we will use the credentials associated with the user who is starting the workspace.
Sometimes though it makes sense to use shared team secret as a way to control git access instead. You can do this by providing a code_clone_credentials
section in the recipe configuration section:
Currently we support two types of credentials: ssh-private-key
and github-token
. Credentials set in config will be used for all git operations during build
and launch
phases for all git-clone
steps.
You are also able to provide git credentials to an individual git step as follows:
Sometimes a secret value (like an ssh key) is not very useful when it's stuck in an environment variable. To help you with this you can make sure the value is available as a file within a scope of a command, or as part of your workspace for example:
Will ensure that while executing git clone
command, the secret is available as /etc/gitconfig
Secrets mounted this way will only be available during the execution of the command, so they will not be part of the final workspace build. As opposed to files created using the file
step.
You can populate any file from secrets by using the standard file step:
Be careful using this during build phase, as you might embed secrets into the build, which usualy is not what you want.
There are some more advanced configuration options for your workspace. These should be used with care, and most of the time you don't really need to change them.
By default all the repositories are cloned in /home/devzero
directory directly, but in some cases you might want your code to be cloned somewhere else like /home/devzero/projects
for example. To achieve that just add a config section with code_clone_root
set:
Workspaces are based on docker containers, thus not everything is persisted across restarts. You can control which directories you want to persist by setting the volumes attribute in the config section:
These are the default volumes that are being persisted. Make sure to include at least /home/devzero
in the list when customizing it, otherwise your workspace might be completely ephemeral.
Environment values and file contents are special in that you can embed secret values into them. The syntax is quite simple:
As you can see - the structure of the expression consists of 3 parts - source (at the moment only secret
is supported) namespace (user
, team
or devzero
) matching user secret registry, team registry, or system secrets like devzero.GITHUB_ACCESS_TOKEN
that comes from github account linked to your devzero account if present and secret name.
As we are using curly braces for variable interpolation, make sure you quote the strings properly:
Note: User secrets cannot be accessed during build time. However, all user secrets are automatically available as environment variables within each user's workspace.
Recipes have two execution stages that you can customize:
Build-time: when recipe is getting saved, after validation.
Launch-time: when a workspace is being launched from a recipe.
Run-time: when a workspace is running (your active coding, app runtime environment)
Irrespective of the stage, blocks will be executed in the order in which they are specified in the recipe.
This stage should be used when caching of the build is helpful, i.e., pre-builds. Our builder uses the YAML specification to create container images that are then run as workspaces, the build images are layered and cached to improve subsequent workspace launch times.
Each command block can be thought of as a layer in a Docker image. They are wrapped in a script and executed within a bash context. In case directory
is specified:
if absolute, it will be used
if relative, it will be relative to /home/devzero
if unspecified, it will default to /home/devzero
name
is used to help reference and understand what is being achieved in a command block.
Note When invoking binaries, its always best-practice to reference them by their absolute paths. For example, /usr/local/go/bin/go
instead of go
. This relates to the following warning
block.
Warning Environment variable set by calling export
are not going to be available in subsequent command blocks. To use them in subsequent blocks, either write to some file, or to /etc/environment
. Please see the previous info
section for more ways to better utilize this.
While recipe builds are cached, updating a lower layer (eg: the first step in your build steps) will cause the cache to get invalidated for all future steps. Therefore, if you edit step 1 in a 5-step recipe, steps 2, 3, 4 and 5 will get rebuilt. If you just edit step 5, the previous steps will be served out of the cache.
Here's an example of some build-time steps:
Use-cases:
Users in your team don't need to wait for workspaces to build.
Users in your team want to start with workspaces that are already configured with golden paths.
These steps are run using systemctl
units at launch-time. Command blocks will be executed in the order in which they are specified in the recipe.
The launch block is used for commands to be executed as launch-time steps.
Here's an example of some launch-time steps:
A workspace is the DevZero environment that a developer works in. A workspace consists of a , a , and all of the underlying infrastructure and resources defined in the workspace's recipe specification. Developers in a team each work from their own workspace, which is generally isolated from another workspace, and can use various IDEs to connect to it. Workspaces are created from a file - this is to allow for developers to start building their environments from pre-defined golden paths, ensuring identical configuration and provisioning settings.
A workspace can be launched in an available region of the users choice. To learn more about how to deploy your workspaces to specific regions and which regions we currently support, check out
When you create a Recipe on the dashboard (at ), this is what you see...
The broad set of steps that go into building and publishing a recipe, and subsequently launching a workspace are as follows:
All steps that involve commands being run are base64-encoded and passed as input to a binary called dzlaunch
(for cleaner handling of outputs from commands) - this binary is also available in a launched workspace.
Once the LLB is ready, its sent to an async queue (buildqd
) for it to get built and made available to be launched as a workspace.
Buildqd
workers are responsible for building OCI-compatible images and pushing it to a team-specific OCI image registry (completely namespaced/isolated).
If there were previous builds of the recipe, those caches are retrieved from the isolated OCI image registry to enable faster builds.
While the build is running, logs are streamed into a message queue to be made available to the different clients (web UI, CLI, etc).
Once the build is completed, the image (and cached layers) are pushed to the team-specific OCI image registry.
There are various ways to interact with your DevBox. The first step is to verify the name of the workspace that you want to interact with.
If you prefer video from, for a 7min video!
You will see something like this...
You can interact with this via:
dz workspace connect <workspace name>
Here's a video covering all these concepts:
If you're not using GitHub or prefer a different authentication method, check out this section on .
Click 'Launch' to create a new Workspace from your Recipe. To connect to your Workspace, you'll need to . From there you can connect with VSCode or a directly with a terminal.
You can also specify :
Semantics for the directory are explained in .
Commands often require either their environment to be set up correctly, or secrets to access private resources. Both of these can be managed on .
We already discussed default code clone credentials in the .
For more examples, see check the build commands in our .
Other than that, the same rules from the stage apply.
To learn more about the various stages of the recipe specification, go to . To learn more about the specification, go to .
YAML recipe converted into an .
If environment variables are referenced (stored under ), they are validated and referenced directly in the LLB.
Environment variables are injected directly into the LLB, and sensitive values (secrets, that are stored in a instance) are referenced and made avaiable to the relevant worker (more on this in step 2.2).
First, LLBs are sent to following a similar pattern to how handles it (but using a directly) - we do this to be able to give the user raw as well as well structured logs.
Secrets, if any, are retrieved from and injected into the build worker - this is one of the ways to ensure logical isolation.
local IDEs [eg: VS Code (), JetBrains ()]
SSH ()
To view running applications, visit <workspacename>:<port>
in your browser (more info on this under !
Get a shell inside the node that you want to add to the network.
Run
Add the node to the network by running (optional --hostname
flag: replace <some_name>
with a memorable hostname)
Verify that the node is in the network by running
Get a shell inside the node that you want to add to the network.
Install the CLI following these steps.
Run
Add the node to the network by running (optional --hostname
flag: replace <some_name>
with a memorable hostname)
Verify that the node is in the network by running
The DevZero Network uses a decentralized VPN strategy to enable secure access to nodes across your team. We accomplish thiusing WireGuard.
Within the DevZero network, nodes either connect peer-to-peer (using NAT Traversal), or through a relay.
Fully-hosted SaaS:
Available at devzero.io/dashboard
Suitable for most software engineering teams with fewer than 250 engineers
You just sign up and start using it! No need to talk to us
Dedicated SaaS:
Available either at devzero.io/dashboard or some other domain
Suitable for teams:
with more than 250 engineers, but fewer than 1000 engineers
who have bespoke compute, security or compliance requirements
You can start by signing up on your own, but you'll need to reach out to support@devzero.io to upgrade your hosting model
Self-hosted:
Hosted on your cloud or on your hardware (We give you terraform scripts that you can use to set things up, with personalized help from our solutions engineers)
Suitable for teams with over 1000 engineers or those operating in regulated markets
Send us a note to support@devzero.io or devzero.io/contact if you care to learn more
DevZero's volumes are multi-attach multi-read-write capable volumes (similar to AWS EFS). Volumes are regional in nature and can be attached to any workspace in that region.
The volume is mounted at the path specified by the --mount
flag.
Volume is a storage device. It may be used only by one workspace, or can be attached to multiple, in a read-write capacity. It usually shows up on a workspace as a filesystem.
Ceph is a free and open-source software-defined storage platform that provides object storage, block storage, and file storage built on a common distributed cluster foundation.
The methodology that's used to enable a workspace to have access to persistent volumes (can be verified by running mount in a UNIX shell).
Persistent volumes are network-backed block devices that are mounted to workspaces. This ensures that changes made inside a workspace are resilient to restarts, etc.
Coming soon... We currently support a handful of predefined user roles and permission sets. Additional customization options are expected to land later this year.
Manage your workspaces, team recipes, and settings
Use the CLI to manage and connect to your DevZero Workspaces
Prebuilt recipe templates for your tools and services
User workspaces are deploying with an ephemeral, namespaced Kubernetes cluster. If you need to interact with this cluster...
If you prefer video from, click here for a 5min video!
To view the config, run
To write the config to the default Kubernetes configuration location, run
Then run commands like
When inside a DevBox context (i.e. when connected to a workspace), the CLI is able to retrieve environmental information from /etc/devzero
.
In a fresh new workspace, you can immediately run:
DevZero reserves the default
namespace for it's managed deployments. Do not operate on this namespace. Adding or removing resources in this namespace will lead to undocumented behaviors and cause potential data loss.
Here's a video covering how you can access and deploy apps to your workspace's Kubernetes cluster...
Securely share workspaces with colleagues or teams to collaborate in real-time.
Virtualized cloud development environment that you connect to using your preferred IDE.
WireGuard based network connecting all of your workspaces and other network resources.
Fully elastic volumes and S3 buckets that you can use alongside your workspaces.
Each workspace comes with its own Kubernetes cluster, backed by flexible nodes and compute.
Globally distributed edge regions allow you to work from anywhere with virtually no latency.
Environment variables are materially public in nature. If you want to store or reference a secret value, see Secrets.
These are usually used by when:
a build is getting created,
a process needs it at launch or runtime
Once an environment variable is saved, it will be visible in the UI or CLI. It will be available at build- or launch-time. It will also be available in the running workspaces.
Reserved prefix DEVZERO_
is a reserved prefix used by the platform. They may change at any time so relying on them is not advisable.
You may store environment variables or secrets with line breaks.
You can access environment variables within builds or at launch-time. If your variable is called MY_KEY
, to access its value anywhere, use $MY_KEY
. At runtime, you can use the env
binary to verify that the secrets are present within that context.
To access environment variables within the workspace, you can define them in the runtime section like this:
Visit the Environment Variables section at https://www.devzero.io/dashboard/environment-variables/user to add, remove, or update your user-scoped environment variables and secrets. User-scoped environment variables can only be seen, managed, and used by you.
User-scoped environment variables are automatically made available on each of your running workspaces by default.
Using an environment variable within your workspace is how you would normally use any environment variable (eg: echo $NOT_SO_SECRET_KEY
).
Note: User secrets are not available during build time, they are only available during launch and runtime steps. However, all user secrets are automatically available as environment variables within each user's workspace.
To use it in a recipe, you can reference it the same way. If your environment variable is called MY_KEY
:
Need to store a secret environment variable? Check out the Secrets page.
Edge compute regions supported by the hosted DevZero platform
Region Code | City Code | Geographic Location | Status |
---|---|---|---|
Workspaces can be launched in any supported DevZero region, provided your team and subscription tier allow for it. When you sign-up for DevZero, you have a default region set. You can change this preference from your user settings page.
To launch a workspace in a certain region, first go to the recipes page at https://www.devzero.io/dashboard/recipes/recipe-library
Click on the recipe you want to launch. Then select the appropriate region in the Workspace region
section:
After you've selected the region you want your workspace to be in, click on Launch
!
Workspaces are be hibernated when inactivity is detected (or when the DevZero platform under conditions of duress). Currently, all the contents under /home/devzero
are backed by a persistent volume.
Therefore, contents outside of /home/devzero
(for example, /var/*
, /tmp/*
, etc) will be lost when such an event occurs.
On the roadmap... Our team is actively working on ways to preserve and restore:
running process
state of the entire filesystem for when a workspace or any of its parts are restarted after being paused/stopped.
Users cannot manually hibernate a workspace, however they are automatically restarted (if in a hibernated state) when you attempt to reconnect to the workspace.
Workspace activity is determined by active connections that it's serving. This could be sessions connected via SSH, via various IDEs, etc. Workspaces are considered to be dormant after 30+ minutes of inactivity, and may be candidates for hibernation.
Make sure you're connected to the DevZero network by running:
The, find the desired workspace by running:
You will see an output that looks like this:
You can use either the hostname or the IP to make network requests when accessing running applications inside the DevBox.
To access an application running inside a DevBox using the cURL command, you can send requests to the desired DevBox using the following URL scheme: <protocol>://<devbox hostname>:<port> or the DevBox IP
Example:
To access an application running inside a DevBox in the Browser, you can open a URL that follows the scheme: <protocol>://<devbox hostname>:<port> or <devbox IP>:<port>
To access your DevBox using ssh, connect to your DevBox with devzero@<devbox hostname> or devzero@<devbox ip> as a credential:
Example:
As long as you're connected to the DevZero network, all the ports available are exposed to your machine automatically.
If you're running applications inside Kubernetes, you might need to use the kubectl port-forward command fo forwards to port of the application to your DevBox.
Example:
The flow for this is exactly the same as all above.
The only difference is, in order to see your teammate's workspace, add the --team
flag to the command.
The rest of the steps are exactly the same!
Secrets are used to store and reference secret values.
To store a secret, navigate to the environment variables page and add a new key-value pair. Before saving, be sure to check "Secret". This stores the environment variable as a secret with the additional protections described below.
Once a secret is saved, its value cannot be viewed or modified. You can only replace or delete the value. Otherwise, secrets work just like other environment variables.
Note: User secrets are not available during build time, they are only available during launch and runtime steps. However, all user secrets are automatically available as environment variables within each user's workspace.
You can access secrets within builds or at build or launch time, just like you would access any environment variable. If your secret is called MY_SECRET_KEY
, to access its value anywhere, use $MY_SECRET_KEY
. At runtime, you can use the env
binary to verify that the secrets are present within that context.
All secrets are securely stored within DevZero in an isolated HashiCorp Vault deployment.
Visit the Environment Variables section at https://www.devzero.io/dashboard/environment-variables/team to add, remove or update your team-scoped environment variables. Team-scoped environment variables can be referenced and used by anyone within your DevZero team.
Team-scoped environment variables and secrets must be directly referenced in your recipe template steps. Unlike user-scoped environment variables, they are not automatically added to every workspace.
Using an environment variable within your workspace is how you would normally use any environment variable (eg: echo $NOT_SO_SECRET_KEY
).
To use it in a build, you can reference it the same way. If your environment variable is called MY_KEY
:
Need to store a secret environment variable? Check out the Secrets page.
Currently, to see the peers that are present within your DevZero network, run
To view all the peers in your team, run
Use-case:
Using your company's SSO to control your team's login to the DevZero Platform
Many organizations use SSO to easily manage onboarding and offboarding of employees and contractors. Logging into your DevZero team can be placed behind your current SSO provider. Currently, corporate SSO support is in private beta. If you would like to enable SSO support for your account, send an email to support@devzero.io with the following information, we can enable SSO for your team!
Sign-on URL (might be the same as [2])
Issuer (might be the same as [1])
Public certificate
Signature method (eg: RSA-SHA256
)
Digest method (eg: SHA256
)
You can also create this as a secret GitHub Gist and send us a link!
Note... We are aware that depending on the SSO provider you use, we might have to provide you a couple bits of information to put in your SSO Admin Portal. We will reach out to you if that's the case!
To manage Personal access tokens, nagivate to and find the "Personal Access Tokens" section
To create a token, click on "Create new token". Once the token is created, be sure to copy and save the token contents somewhere secure, it will not be shown again.
Deleting a token is performed in the same section.
A personal access token can be used to authenticate the dz
cli. Simply log in by passing the token contents via the --token
flag. Upon token expiry, the cli will prompt to re-authenticate.
Connecting to DocumentDB running in the private subnet of AWS VPC from your DevBox.
Go to Amazon DocumentDB > Clusters > Your Cluster.
Select Connectivity & Security. You will see the commands and DocumentDB hostname for accessing it.
In your DevBox, import the MongoDB public GPG key:
Add MongoDB package repository source:
Reload local package database:
Install MongoDB:
Download the certificate:
Connect to the database:
where the cluster endpoint will be available in Connectivity & Security section.
Go to Amazon DocumentDB > Create Cluster.
Select Instance Based Cluster.
In the Configuration section choose Instance Class, number of instances for your cluster.
Set Username and Password.
Turn on Show advanced settings.
In the Network settings , choose the VPC where your bastion host is running, subnet group and assign a security group which has inbound access to only VPC.
Click Create cluster.
In your DevBox, import the MongoDB public GPG key:
Add MongoDB package repository source:
Reload local package database:
Install MongoDB:
Download the certificate:
Connect to the database:
where the cluster endpoint will be available in Connectivity & Security section.
Connecting to EKS running in the private subnet of AWS VPC from your DevBox.
Go to Amazon Elastic Kubernetes Service > Clusters.
Go to your DevBox and install awscli:
Download the kubectl binaries:
Install kubectl:
Check if the cluster is accessible:
Go to Amazon Elastic Kubernetes Service > Clusters > Add cluster > Create.
Enter the name of the cluster and assign a Cluster service role which has AmazonEKSClusterPolicy permission. If no role is present, create a new one with the same permission.
Click on Next. In the Networking section, choose the VPC where your bastion host is deployed and assign 2 private subnets. In Cluster endpoint access, select Private.
Configure other configurations as required and then create the cluster. After creating the cluster, go to the compute section and under Node groups click on Add node group.
Enter the name of the node group and assign a node IAM role with AmazonEC2ContainerRegistryReadOnly, AmazonEKS_CNI_Policy and AmazonEKSWorkerNodePolicy permissions. If no role is present, create a new one with the same permissions.
Configure other configurations as required and create the nodes.
Go to your DevBox and install awscli:
Download kubectl binaries:
Install kubectl:
Click on your AWS username at the top right corner and go to Security credentials. In the Access keys section, click on Create access key. Create the key and save the CSV file.
In your DevBox, use the csv credentials to configure the awscli to your account:
Check if the cluster is accessible:
``` kubectl get svc
DevZero Dashboard
dz CLI
Starter Templates
Secure Environments
DevBox
Network
Storage
Ephemeral K8s Cluster
Edge Regions
Follow the guide.
Follow the guide.
Follow guide.
You can run services and tasks managed by AWS ECS inside of DevBoxes using AWS ECS Anywhere.
Create a new cluster or start with an existing one. Note: you can only register external nodes after the cluster has been created.
Visit Your Cluster > Infrastructure > Container Instances.
Click on "Register external instances".
In the popup, confirm the settings and click on "Generate registration command".
Copy the command for Linux. You will need it later.
In your DevZero box, download the installation script for ECS Anywhere:
Make sure the the downloaded script has the correct permissions:
Run the installation script with the parameters from the command in step #5:
Note: the installation script will also install Docker.
The new instance should now be visible in the ECS console under Your Cluster > Infrastructure > Container instances as "External" instance type.
If you want to add volumes to your services/tasks:
Go to your Task definition.
Scroll down to the "Storage" section.
Click on the "Add volume" button.
Enter the volume name.
In "Configuration type", select "Configure at task definition creation".
Choose "Docker volume" in the "Volume type" section.
Under "Driver" enter "local" and select "Task" as Scope.
Create a new container mount point: Select the container in question, the source volume and enter a mount path.
The new volume should now be available after your task has been created:
If you select "Configure at deployment" in your task definition, you might not be able to deploy it to the external instance type, because this configuration only supports Amazon EBS, which is not available with external instances.
When running tasks/services you should now be able to select "External" launch type in order to run them on your DevBoxes.
usw2
PDX
Portland, Oregon, USA
use1
IAD
Washington, D.C., USA
sae1
GRU
São Paulo, Brazil
aps1
BOM
Mumbai, India
apse1
SIN
Singapore, SG
euw1
DUB
Dublin, Ireland
apse2
SYD
Sydney, Australia
apne1
HND
Tokyo, Japan
-
OTP
Bucharest, Romania
-
DFW
Dallas, Texas, USA
-
ORD
Chicago, Illinois, USA
afs1
JNB
Johannesburg, South Africa
cac1
YYZ
Toronto, Ontario, Canada
-
WAW
Warsaw, Poland
Connecting to EC2 running in the private subnet of AWS VPC from your DevBox.
Follow the Connecting to AWS guide.
Go to Amazon EC2 > Instances > Your Instance.
Click on Connect. You will see the commands for accessing it.
Go to DevBox and make a copy of the key pair.
Connect to EC2 machine:
Follow the Connecting to AWS guide.
Go to Amazon EC2 > Instances > Launch Instances.
Enter the name of the instance.
Use one of the supported linux distros.
Choose the Instance type.
Create a new key pair and save it.
In the Network settings, click on edit and choose the VPC where your bastion host is running, the private subnet and the security group which allows inbound access to VPC.
Go to the DevBox and make a copy of the key pair.
Connect to the desired EC2 instance using ssh and the new key pair:
Connecting to ElastiCache running in the private subnet of AWS VPC from your DevBox.
Follow Connecting to AWS guide.
Go to Amazon ElastiCache > Redis OSS Cache > Your Cluster.
Select Configuration & Security.
Copy Primary endpoint.
Go to your DevBox and install the Redis CLI:
Access the cluster using the CLI:
Go to Amazon ElastiCache > Create.
Select Design your own cache.
Select Cluster cache in the Creation method.
Use the default configurations for creating the cluster.
Scroll Down to the Cluster info and specify your Cluster Name.
Choose the Engine Version and Node Type in the Cluster settings.
Go to Connectivity section and choose your VPC and Subnet group.
In the next section, choose the Security Group. Make sure the specified Security Group allows inbound connection from the VPC.
Click on Create.
Go to your ElastiCache and copy Primary endpoint.
Go to your DevBox and install the Redis CLI:
Access the cluster using the CLI:
You are connecting to a Kubernetes cluster running in the private subnet of Azure Virtual Network (VNET) from your DevBox.
Here, you will connect to a Kubernetes cluster running in a private subnet from your DevBox. This would be done by setting up a bastion host that advertises the VNET CIDR to your DevZero network so that you can access the private service through the network tunneling.
To connect to AKS running in the private subnet, ensure it is within the same Resource Group and VNET containing the Bastion Host.
If the above criteria are followed, then log into your DevBox and follow these steps:
Go to your DevBox and install Azure CLI:
After the installation is successful, you need to authenticate your Microsoft Azure account with Azure CLI using the following command:
Following your setup with Azure CLI, you also need to download the kubectl binaries:
Install kubectl:
After your initial setup is done, your DevBox should be ready for accessing the cluster:
You need to select your Subscription ID in Azure Cli with the following command:
Use the following command to connect to your cluster:
Check if the cluster is accessible:
If you need to make a new AKS Cluster running in a private subnet and access it through DevZero's network, then follow the below steps:
Go to Home > Kubernetes Services or you can search for Azure Kuberntes Service in the search bar and click on Create Kubernetes Cluster.
In the Basics section, select the resource group you previously selected for your VNET.
Enter your Cluster name and region and choose your desired node image.
Select your desired Node Pool machine configuration in the Node Pools section.
Go to the Networking section and check the Enable private cluster
and Bring your own Azure virtual network
options, respectively.
After checking these two options, you will be asked to choose your VNET. Then, create a new subnet dedicated to Kubernetes and choose that subnet.
Enter a Kubernetes service address range that doesn't overlap with your VNET CIDR. For Example, if your VNET CIDR Range is 10.0.0.0/16, then it is recommended that you make your Kubernetes service address range 192.168.0.0/16.
Provide a Kubernetes DNS service IP Address and enter your DNS name prefix.
Click on Review + Create and click on Create to create Kubernetes Cluster.
Now that you have created the cluster, you need to authenticate your DevBox with the az
cli tool:
Go to your DevBox and install Azure CLI:
After the installation is successful, you need to authenticate your Microsoft Azure account with Azure CLI using the following command:
Following your setup with Azure CLI, you also need to download the kubectl binaries:
Install kubectl:
After your initial setup is done, your DevBox should be ready for accessing the cluster:
You need to select your Subscription ID in Azure CLI with the following command:
Use the following command to connect to your cluster:
Check if the cluster is accessible:
This guide explains connecting to an AWS DynamoDB service running on AWS infrastructure from your DevBox.
If you already have a DynamoDB, you can follow the steps below to access its content from the DevBox.
First, we need to create a recipe for the workspace:
Enter the recipe name and click on Create a recipe.
Now use the below-provided snippet to create a recipe for your workspace:
Click on Save and Build and when the build is successful, click on Publish.
Enter the workspace name and click on Select from recipe library.
Select the recipe you just created above and click on Select.
Click on Launch, and your workspace will be ready shortly.
Now, this is where the real task begins. After downloading the `aws' cli package, we will need to authenticate with our AWS account. To do so, follow the below steps:
Go to AWS Dashboard, and on the top right corner, click on the drop-down menu and select Security credentials.
Under the Access Keys section, click on Create Access Key and agree to the Terms and Conditions.
Click create access key
and note down the Secret Access Key as this will only be shown once.
Go to your DevBox and use the following command to configure the aws
cli:
Enter the Access Key and Secret Access Key when prompted.
Enter your default Region of choice, and your aws
cli setup will be completed.
Now, with the above steps, your AWS DynamoDB connections are completed, and you can check that with the following command:
Setting up a DNS Private Resolver so that you can access the Azure Private DNS zones connected to your Azure Virtual Network (VNET).
Here, you will setup DNS Private Resolver through which you would resolve DNS queries from the DNS Private zones and direct them to the Bastion Host. The Bastion Host will then forward those queries to the DevZero Network through advertised routes.
To create a DNS Private Resolver, you need to ensure that you have no other DNS Private Resolver instances in your Resource Group.
If the above criteria are followed, then follow these steps:
Go to Home > DNS Private Resolvers and click on Create.
Enter Subscription and Resource Group name in the Project Details section.
Then enter the instance name and region. Remember to choose the region which houses your VNET.
Then select your Virtual Network (VNET).
In the Inbound Endpoint page, click on Add an endpoint and then enter the endpoint name.
While selecting the subnet for Inbound Endpoint, create a new subnet and then click on Save.
Click on Review + Create and click on Create to create the DNS Private Resolver.
After you are done with creating the DNS Private Resolver, you need to add the DNS IP address to the DevZero Network so that you can use the Azure DNS Private Zones.
Go to Home > DNS Private Resolver and click on the new DNS Private Resolver you just created.
Then navigate to Settings > Inbound Endpoints and note down the IP Address of the inbound endpoint which you created.
Go to DevBox and enter the following command:
we need to add the IP address to this configuration file so that the DevZero Network can use the Conditional Forwarder.
Enter the following line to the resolv.conf
file:
save the file and you will now be able to access the domains within the Azure DNS Private Zones.
For Example, we have a DNS Private Zone named privatelink.postgres.database.azure.com
and it houses a private domain endpoint named test-db-devzero.postgres.database.azure.com
. You can verify the setup by using nslookup
:
If everything goes well then you should see a output similar to this.
Install the into your DevBox.
Go to AWS Console > IAM > Users > Create user.
Add the following permissions to the user: AmazonS3FullAccess.
After you obtained the credentials, log into the AWS CLI by running:
Update your S3 access policy to allow access to the new user.
Verify you can query the S3 bucket:
Follow the guide.
Go to VPC > Endpoints > Create Endpoint.
Enter a name then select "AWS Services" as your Service category.
In the "Services" search bar type "S3" and select the suggested service (Interface).
Under VPC, select your EC2 "relay" VPC.
Select the desired subnets.
Select the desired security groups. Make sure that you allow inbound/outbound access to/from your EC2 instance.
Specify custom VPC endpoint policies, if required.
Click on "Create endpoint" to proceed.
Set your S3 Bucket policy as follows:
Running the following in your DevBox terminal:
Will result in:
Running the same command with a custom endpoint should result in no errors however:
Connecting to OpenSearch running in the private subnet of AWS VPC from your DevBox.
Go to Amazon OpenSearch Service > Domains.
Select your domain and copy your Domain Endpoint.
Go to your DevBox and connect to Service:
Go to Amazon OpenSearch Service > Create domain.
Give a unique Domain name.
Select Standard create in the Creation method.
Use the default configurations for creating the service.
Keep the Data nodes according to your requirements.
Go to Network section and choose your VPC and Subnets.
In the next section, choose the Security Group. Make sure the specified Security Group allows inbound connection from the VPC
Click on Create.
Go to your OpenSearch and copy Domain endpoint.
Go to your DevBox and connect to Service:
Install the into your DevBox.
Go to AWS Console > IAM > Users > Create user.
Add the following permissions to the user: AmazonSQSFullAccess.
After you obtained the credentials, log into the AWS CLI by running:
Update your SQS access policy to allow access to the new user.
Send a test message to the queue:
Verify you can recieve the messages:
Follow the guide.
Go to VPC > Endpoints > Create Endpoint.
Enter a name then select "AWS Services" as your Service category.
In the "Services" search bar type "SQS" and select the suggested service.
Under VPC, select your EC2 "relay" VPC.
Select the desired subnets.
Select the desired security groups. Make sure that you allow inbound/outbound access to/from your EC2 instance.
Specify custom VPC endpoint policies, if required.
Click on "Create endpoint" to proceed.
Set your SQS-queue policy as follows:
Running the following in your DevBox terminal:
Will result in:
Running the same command with a custom endpoint should result in no errors however:
You are connecting to a Azure database instance running in the private subnet of Azure Virtual Network (VNET) from your DevBox.
Here, you will connect to a private Azure database instance from your DevBox. This would be done by setting up a bastion host that advertises the private routes to your DevZero network so that you can access the private service through network tunneling.
To connect to a database running in the private subnet, ensure it is within the same Resource Group and VNET containing the Bastion Host.
Now follow the below steps to access the Database instance on your DevBox:
Go to DevBox.
To Setup Database client and connect to the instance, follow these steps:
To install the mysql client cli:
To access the database:
To install the psql client cli:
To access the database:
If you need to make a new database running in a private subnet and access it through DevZero's network, then follow the below steps:
Go to Home > Azure Database for MySQL servers and click on Create.
In the Basics section, select the Resource group you previously selected for your VNET.
Then input your database Server name, Region and the desired MySQL version.
Remember to select the region where your VNET resides.
Under the Authentication section, Enter your Admin Username and password.
Go to the Networking page and under Network connectivity choose Private access (VNet Integration) option as we need to make the instance private.
In the Virtual Network section, select the VNET and Private Subnet.
Click on Review + Create and click on Create to create the database.
Go to Home > Azure Database for PostgresSQL servers and click on Create.
In the Basics section, select the Resource group you previously selected for your VNET.
Then input your database Server name, Region and the desired PostgresSQL version.
Remember to select the region where your VNET resides.
Under the Authentication section, Enter your Admin Username and password.
Go to the Networking page and under Network connectivity choose Private access (VNet Integration) option as we need to make the instance private.
In the Virtual Network section, select the VNET and Private Subnet.
Click on Review + Create and click on Create to create the database.
Now you just need to follow the below steps to install the database clients and connect to DevBox:
Go to DevBox.
To Setup Database client and connect to the instance, follow the steps:
To install the mysql client cli:
To access the database:
To install the psql client cli:
To access the database:
Connecting to an RDS running in the private subnet of AWS VPC to your DevBox.
Go to RDS > DB Instances > DB Name.
Select Connectivity and Security.
Copy Endpoint.
Go to DevBox.
Connecting to the Database.
Run the following commands as per the RDS Database Engine:
To install the mysql client cli:
To access the database:
To install the psql client cli:
To access the database:
Go to RDS > DB Instances.
Select Standard Create.
Choose the Available Versions of the Database.
Choose the Templates based on your use-case. It could be Production or Dev/Test.
Scroll Down to the Settings and specify your Database Name.
Choose Cluster Storage Configuration and DB Instance Class.
Go to Connectivity > VPC.
Choose your VPC , DB Subnet Group and Security Group. Make sure the specified Security Group allows inbound db connections.
Click on Create Database.
You will see two endpoints. Copy Writer Type Endpoint.
Go to the Secrets Manager.
Click on Retrieve Secret Value. This secret is storing your Database Username and Password.
Go to DevBox.
Connecting to the Database:
psql -h <RDS Endpoint> --username <Username> -d <Database Name> --password
You are connecting to an Azure Key Vault from your DevBox.
Here, you will connect to a Key Vault from your DevBox. This would be done by setting up a bastion host that advertises the private routes to your DevZero network so that you can access the private service through network tunneling.
To connect to an existing Key Vault, ensure it is within the same Resource Group that houses the Bastion Host.
To make the connection, you need to set up the IAM role and install dependencies in your DevBox.
Go to Home > Key Vaults and click on the key vault you want to access.
Then go to Access Control (IAM) and click on Add role assignment.
Click on the Key Vault Reader role and click on next.
Click on Select Members and select the users you want to give access to the Key Vault. Click on Select.
Then click on Next and then click on Review + Assign to assign the role.
Now, you can read the Secrets in the key vault without error.
We are assuming the Key Vault is private, and in this case, you will not be able to see the value of the secret. For some reason, if you want to see the value of the secrets, then turn the access to Public in the Settings > Networking section. After viewing the value of the secret, Disable the Public Access again.
Now, to retrieve the value from the secrets using the API, you need to set Service Principals on the Azure Portal using the below steps:
Go to Microsoft Entra ID and click on App registrations.
Click on New registration, enter the app name as you like, and click on Register.
Go to All applications and click on the app you just created.
Copy the Client ID and Tenant ID and add it to the DevBox environmental variables.
Click on Client credentials and click on New client secret.
Enter the description if you want to, and click on Add.
Copy the Value of the client secret you just created and add it to the environmental variables of your DevBox by using the following command.
Now, go to Home > Key Vaults and click on the key vault you want to access.
Then go to Access Control (IAM) and click on Add role assignment.
Click on the Key Vault Reader role and click on next.
Click on Select Members and select the App Name you just registered in Microsoft Entra ID. Click on Select.
Then click on Next and then click on Review + Assign to assign the role.
Here we are using Python to show the key vault usage, you can choose other programming stack as well. Now, you need to install the necessary packages in Python to write the script by following the below steps:
Install the required packages using the following command:
Write the following Python script to retrieve the secret:
If you need to make a new Key Vault and access it through DevBox, then follow the below steps:
Go to Home > Key vaults and click on Create.
In the Basics section, select the Resource group which houses your Bastion Host.
Then input your Key Vault name, Region and the desired Pricing Tier.
You can set the Days to retain deleted vaults duration as you like.
Go to the Networking page and disable the Enable public access and enable the Private Endpoint section.
Click on Create a private endpoint and enter the Resource group, Location, Name, and Target sub-resource type of the endpoint.
In the Networking section, select the virtual network (VNET) you used to set up the DNS resolver and Bastion Host.
Choose a compatible subnet or create a new one, and a new private DNS zone will be created for you.
Click on Ok, then click on Review + Create.
Click on Create to initialize the deployment for the key vault.
To make the connection, you need to set up the IAM Role and install dependencies in your DevBox.
Go to Home > Key Vaults and click on the key vault you just created.
Then go to Access Control (IAM) and click on Add role assignment.
Click on the Key Vault Reader role and click on next.
Click on Select Members and select the users you want to give access to the Key Vault. Click on Select.
Then click on Next and then click on Review + Assign to assign the role.
Now go to Obejcts > Secrets and click on Generate/Import.
Enter the Name and Secret Value and click on Create.
In this case, the Key Vault is private, and you will not be able to see the value of the secret. For some reason, if you want to see the value of the secrets, then turn the access to Public in the Settings > Networking section. After viewing the value of the secret, Disable the Public Access again.
Now, to retrieve the value from the secrets using the API, you need to set Service Principals on the Azure Portal using the below steps:
Go to Microsoft Entra ID and click on App registrations.
Click on New registration, enter the app name as you like, and click on Register.
Go to All applications and click on the app you just created.
Copy the Client ID and Tenant ID and add it to the DevBox environmental variables.
Click on Client credentials and click on New client secret.
Enter the description if you want to, and click on Add.
Copy the Value of the client secret you just created and add it to the environmental variables of your DevBox by using the following command.
Now, go to Home > Key Vaults and click on the key vault you want to access.
Then go to Access Control (IAM) and click on Add role assignment.
Click on the Key Vault Reader role and click on next.
Click on Select Members and select the App Name you just registered in Microsoft Entra ID. Click on Select.
Then click on Next and then click on Review + Assign to assign the role.
Here we are using Python to show the key vault usage, you can choose other programming stack as well. Now, you need to install the necessary packages in Python to write the script by following the below steps:
Install the required packages using the following command:
Write the following Python script to retrieve the secret:
Connecting to an Azure Blob Storage from your DevBox.
Here, you will connect to a Blob Storage from your DevBox. This would be done by setting up a bastion host that advertises the private routes to your DevZero network so that you can access the private service through network tunneling. You must also set up a DNS Private Resolver to access the Blob Storage's Private Endpoint from your DevBox.
To connect to a Storage Account, ensure it is within the same Resource Group containing the Bastion Host.
Now follow the below steps to access the Blob Storage on your DevBox:
Go to DevBox and install the Azure CLI tool using the following command:
Login into your Azure account using the login
command:
After you have completed your authentication, go to Home > Storage Accounts and select your storage account.
Then go to the Security + Networking > Access Keys section and note down either of the two access keys presented to you.
After you have acquired the access key, you may use the following command to Upload, Download, or list the blob in the container:
To Upload a file as Blob to the container, use the following command:
To Download a Blob from the container, use the following command:
To list all the blobs in the container, use the following command:
If you need to make a new Blob Storage and access it through DevBox, then follow the below steps:
After the above mentioned steps are completed, you may go ahead and create a container for Blob Storage by following these steps:
Go to Home > Storage Accounts and click on your storage account.
Go to the Data Storage tab and click on Containers.
Create a new container by entering the container name and clicking on Create.
After creating the container, go to the Security + Networking > Access Keys section and note down either access key.
After creating the container, you must install and authenticate your Azure CLI to easily access Blob Storage. To do so, you may follow the below steps:
Go to DevBox and install the Azure CLI tool using the following command:
Login into your Azure account using the login
command:
You may use the following command to Upload, Download, or list the Blob in the container:
To Upload a file as Blob to the container, use the following command:
To Download a file from the container, use the following command:
To list all the blobs in the container, use the following command:
You are connecting to a Virtual Machine running in the private subnet of Azure Virtual Network (VNET) from your DevBox.
Here, you will connect to a virtual machine running in a private subnet from your DevBox. This would be done by setting up a bastion host that advertises the VNET CIDR to your DevZero network so that you can access the private service through the network tunneling.
To connect to a Virtual Machine running in the private subnet, ensure it is within the same Resource Group and VNET containing the Bastion Host.
If the above criteria are followed, then log into your DevBox and SSH into the private VM by following these steps:
Go to DevBox.
Copy the private SSH key within the .ssh
directory.
Connect to the virtual machine:
If you need to make a new virtual machine running in a private subnet and access it through DevZero's network, then follow the below steps:
Go to Home > Virtual Machines > Create a virtual machine.
In the Basics section, select the resource group you previously selected for your VNET.
Enter your desired username and select the allow selected ports for the Public inbound ports option.
Go to the Networking section and enter your Virtual Network (VNET). Please remember to choose None in the public IP option because we must make the instance private.
Select the Basic option for the NIC network security group. It will create a security group for you that allows port access for SSH.
Click on Review + Create and click on Create to create virtual machine.
Download the SSH private key when prompted. This will help you SSH into the Bastion Host later.
Go to DevBox and make a copy of the key pair.
Connect to the Virtual Machine using ssh and the new key pair:
You are connecting to a Container Instance running in the private subnet of Azure Virtual Network (VNET) from your DevBox.
Please make sure your container has a Private IP Address and check if the container is housed in the same Virtual Network as the Bastion Host.
First of all, we need to create a workspace:
Navigate to the Workspaces tab and click on New workspace.
Enter the workspace name and click on Select from recipe library.
Click on New Recipe and enter the recipe name and click on Create a recipe.
Select a workspace region and click on Launch.
Follow the Below steps to access your container application from your DevBox :
Connect to the workspace using the following command:
You can access the application running in the container using the curl
command:
If you need to make a new container running in a private subnet and access it through DevZero's network, then follow the below steps:
Go to Home > Container Instances and click on Create.
In the Basics section, select the Resource group you previously selected for your VNET.
Then input your Container name and Region and choose your desired SKU.
Choose your desired Image source between Quickstart images
, Azure Container Registry
, and Other registry
.
We will work with Quickstart images
for this guide.
Select or input the Image and choose the desired size configuration for your container.
On the networking page, choose the Private option and select your VNET and desired subnet.
Click on Review + Create and click on Create to create container.
Follow the steps to create a workspace:
Navigate to the Workspaces tab and click on New workspace.
Enter the workspace name and click on Select from recipe library.
Click on New Recipe and enter the recipe name and click on Create a recipe.
Select a workspace region and click on Launch.
Follow the Below steps to access your container application from your DevBox :
Connect to the workspace using the following command:
You can access the application running in the container using the curl
command:
Before you begin, follow the guide to set up the Bastion Host to access your private Azure services.
is a serverless, NoSQL, fully managed database. You will connect through the aws
cli tool by first authenticating into your AWS Cloud account and then accessing the contents of the DynamoDB Service.
Go to the and click on New recipe.
Go to the by clicking New workspace.
Before you begin, follow the guide to set up the Bastion Host to access your private Azure services.
Follow guide.
Before you begin, follow the guide to set up the Bastion Host to access your private Azure services.
If the above criteria is followed then follow the guide to access the DNS Private Zones.
After creating the database, you need to follow the guide to access the DNS Private Zones which houses your database's private domain endpoint for easy access.
Follow the guide.
Follow the guide.
Use one of the in the Configuration.
Before you begin, follow the guide to set up the Bastion Host to access your private Azure services.
Following the above criteria, follow the guide to access the DNS Private Zones.
Before you begin, follow the guide to set up the Bastion Host to access your private Azure services.
Following the above criteria, follow the guide to access the DNS Private Zones.
After successfully setting up the DNS Private Resolver, follow the guide to access the storage account endpoint.
Firstly, you must follow the guide to create and configure a new storage account. After the setup, you must also set up the DNS Private Resolver by following the guide.
Before you begin, follow the guide to set up the Bastion Host to access your private Azure services.
Then input your VM name and region and choose your desired image. You can view the available images .
is a serverless container service that allows you to run isolated containers in Azure without managing underlying infrastructure or orchestrating container deployments. This would occur by setting up a bastion host that advertises the VNET CIDR to your DevZero network so you can access the private service through the network tunneling.
Before you begin, follow the guide to set up the Bastion Host to access your private Azure services.
Go to .
To to .
You connect to an Azure Elastic SAN Service running on Azure infrastructure from your DevBox.
Azure Elastic SAN is a fully integrated solution that simplifies deploying, scaling, managing, and configuring a SAN while also offering built-in cloud capabilities like high availability. This connection will occur by setting up a bastion host that advertises the private routes to your DevZero network so you can access the private service through network tunneling. You must also set up a DNS Private Resolver to access the Elastic SAN's Private Endpoint from your DevBox.
Before you begin, follow the Connecting to Azure guide to set up the Bastion Host to access your private Azure services.
Following the above criteria, follow the Setting up DNS Private Resolver guide to access the DNS Private Zones.
Ensure the existing SAN is in the same resource group that houses the Bastion Host.
First, we need to create a recipe for the workspace:
Go to the DevZero Dashboard > Recipes and click on New recipe.
Enter the recipe name and click on Create a recipe.
Now use the below-provided snippet to create a recipe for your workspace:
Click on Save and Build and when the build is successful, click on Publish.
Go to the Devzero Dashboard > Workspaces by clicking New workspace.
Enter the workspace name and click on Select from recipe library.
Select the recipe you just created above and click on Select.
Click on Launch, and your workspace will be ready shortly.
To connect to the Elastic SAN volumes, we first need to create a Volume Group and give it private endpoint access:
Go to Home > Azure Elastic SAN and click on the SAN you want to access.
Go to Volume groups and click on Create.
Enter the Volume group name and click on Next.
Click on Create a private endpoint and enter the Resource group, Location, Name and select the Volume group you just created.
Select the Virtual network and choose an available subnet.
Select Yes for Integrate with private DNS zone option, and click on Ok.
After creating the endpoint, click on Create.
You can also add your VNET by clicking on Create under the Virtual Networks section and entering the details of the VNET, which exists in the same region as the Elastic SAN instance.
Now, with everything set, we need to create a volume and generate the connection script:
Go to Home > Azure Elastic SAN and click on the SAN you want to access.
Go to Volumes and click on Create volume.
Choose the Volume group and enter the Volume name, Source type and Size of the volume.
Click on Create and wait for it to initialize.
After creating the volume, select the volume and click on Connect.
Note down the script code for Linux as we will use it to connect Azure infrastructure and the DevBox.
Now you need to follow the below steps to connect to DevBox:
Connect to the workspace from your terminal.
Create a Python script by using the following command:
Paste in the connection script we got from the volume.
Run the Python file with elevated access to make the connection:
If you need to make a new Elastic SAN instance and access it through DevZero's network, then follow the below steps:
Go to Home > Azure Elastic SAN and click on Create.
In the Basics section, select the Resource group you previously selected for your VNET.
Then input your SAN Name, Region, and Redundancy type.
You can allocate the desired SAN size in the Resource provisioning on Elastic SAN section.
Remember that the size of your SAN is directly proportional to the IOPS (Input/Output operations per second) and bandwidth allocated to the instance.
In the Networking section, choose the Disabled option for Public network access.
You can also choose the Enabled option and connect to a VNET if you have a VNET in the same Region as the Elastic SAN instance.
Click on Review + Create and click on Create.
Go to the DevZero Dashboard > Recipes and click on New recipe.
Enter the recipe name and click on Create a recipe.
Now use the below-provided snippet to create a recipe for your workspace:
Click on Save and Build and when the build is successful, click on Publish.
Go to the Devzero Dashboard > Workspaces and click on New workspace.
Enter the workspace name and click on Select from recipe library.
Select the recipe you just created and click on Select.
Click on Launch, and your workspace will be ready shortly.
To connect to the Elastic SAN volumes, we first need to create a Volume Group and give it private endpoint access:
Go to Home > Azure Elastic SAN and click on the SAN you want to access.
Go to Volume groups and click on Create.
Enter the Volume group name and click on Next.
Click on Create a private endpoint and enter the Resource group, Location, Name and select the Volume group you just created.
Select the Virtual network and choose an available subnet.
Select Yes for Integrate with private DNS zone option, and click on Ok.
After creating the endpoint, click on Create.
You can also add your VNET by clicking on Create under the Virtual Networks section and entering the details of the VNET, which exists in the same region as the Elastic SAN instance.
Now, with everything set, we need to create a volume and generate the connection script:
Go to Home > Azure Elastic SAN and click on the SAN you want to access.
Go to Volumes and click on Create volume.
Choose the Volume group and enter the Volume name, Source type and Size of the volume.
Click on Create and wait for it to initialize.
After creating the volume, select the volume and click on Connect.
Note down the script code for Linux as we will use it to connect Azure infrastructure and the DevBox.
Now, you need to follow the below steps to connect to DevBox:
Connect to the workspace from your terminal.
Create a Python script by using the following command:
paste in the connection script we got from the volume.
Run the Python file with elevated access to make the connection:
Connecting to Compute Instance running in the private subnet of GCP VPC from your DevBox.
Follow Connecting to GCP guide.
Go to Compute Engine > VM Instances.
Click on SSH. You will see the commands for accessing it.
Go to DevBox and make a copy of the key pair.
Connect to Compute Instance:
Go to Compute Engine > Create Instance.
Enter the name of the instance along with region and machine type.
Use one of the supported linux distros.
Choose the Instance type.
Go to Advanced Options > Networking > Network Tags and enter the firewall tags.
Go to Advanced Options > Networking > Network Interfaces, click on Network and choose the VPC where your bastion host is running, then click on Subnetwork and choose the private subnet.
Copy the newly created SSH key pair once the instance is created.
Go to the DevBox and make a copy of the key pair.
Connect to the desired Compute instance using ssh and the new key pair:
Connecting to an Azure File Storage from your DevBox.
Azure File Storage is a fully managed file share in the cloud that is accessible via the industry-standard Server Message Block (SMB) protocol, Network File System (NFS) protocol, and Azure Files REST API. Azure file shares can be mounted concurrently by cloud or on-premises deployments. SMB Azure file shares are accessible from Windows, Linux, and macOS clients.
This connection between the Azure File Share and your DevBox would occur by setting up a bastion host that advertises the private routes to your DevZero network so you can access the private service through network tunneling. You must also set up a DNS Private Resolver to access the File Storage's Private Endpoint from your DevBox.
Before you begin, follow the Connecting to Azure guide to set up the Bastion Host to access your private Azure services.
Following the above criteria, follow the Setting up DNS Private Resolver guide to access the DNS Private Zones.
After successfully setting up the DNS Private Resolver, follow the Configuring Storage Account guide to access the storage account endpoint.
To connect to a Storage Account, ensure it is within the same Resource Group containing the Bastion Host.
First, we need to create a recipe for the workspace:
Go to the DevZero Dashboard > Recipes and click on New recipe.
Enter the recipe name and click on Create a recipe.
Now use the below-provided snippet to create a recipe for your workspace:
Click on Save and Build and when the build is successful, click on Publish.
Go to the Devzero Dashboard > Workspaces and click on New workspace.
Enter the workspace name and click on Select from recipe library.
Select the recipe you just created and click on Select.
Click on Launch, and your workspace will be ready shortly.
Now follow the below steps to access the File Storage on your DevBox:
Connect to DevBox and login into your Azure account using the login
command:
After you have completed your authentication, go to Home > Storage Accounts and select your storage account.
Then go to the Security + Networking > Access Keys section and note down either of the two access keys presented to you.
After you have acquired the access key, you may use the following command to Upload, Download, or list the files in the file share:
To Upload a file to the file share, use the following command:
Here, the --source
tag refers to the File you want to upload, and the --path
tag specifies where you want to upload the File, specifying a directory and output file name.
To Download a file from the file share, use the following command:
Here, the --path
tag refers to the terminal path of the File you want to download from your file share and the --dest
tag specifies how and where you want to save your File by specifying a directory and output file name.
To list all the files in the file share, use the following command:
If you need to make a new File Storage and access it through DevBox, then follow the below steps:
Firstly, you must follow the Configuring Storage Account guide to create and configure a new storage account. After the setup, you must also set up the DNS Private Resolver by following the Setting up DNS Private Resolver guide.
After the steps mentioned earlier are completed, you may go ahead and create a file share for File Storage by following these steps:
Go to Home > Storage Accounts and click on your storage account.
Go to the Data Storage tab and click on File Shares.
Create a new File Share by entering the file share name and clicking on Create.
After creating the file share, go to the Security + Networking > Access Keys section and note down either access key.
First, we need to create a recipe for the workspace:
Go to the DevZero Dashboard > Recipes and click on New recipe.
Enter the recipe name and click on Create a recipe.
Now use the below-provided snippet to create a recipe for your workspace:
Click on Save and Build and when the build is successful, click on Publish.
Go to the Devzero Dashboard > Workspaces and click on New workspace.
Enter the workspace name and click on Select from recipe library.
Select the recipe you just created and click on Select.
Click on Launch, and your workspace will be ready shortly.
After creating the File Share, you must install and authenticate your Azure CLI to easily access File Storage. To do so, you may follow the below steps:
Connect to your DevBox and login into your Azure account using the login
command:
Use the following command to create a directory in the File Share:
You may use the following command to Upload, Download, or list the File in the File Share:
To Upload a file to the file share, use the following command:
Here, the --source
tag refers to the file you want to upload, and the --path
tag refers to where you want to upload the file by specifying a Filectory and output file name.
To Download a file from the file share, use the following command:
Here, the --path
tag refers to the terminal path of the file you want to downfile from your file share, and --dest
tag refers to how and where you want to save your File by specifying a directory and output file name.
To list all the files in the file share, use the following command:
Connecting to GCP BigQuery Service from your DevBox.
Go to IAM & Admin > Service Accounts.
Click on Create Service Account, enter the Service Account Name and click on Create and Continue.
Click on Select a role, select BigQuery Admin, and click on Continue.
Select the new service account and go to Keys.
Click on Add Key > Create a new key and click on Create.
Connect to your DevZero workspace.
Store the Google Authentication Credentials on the workspace.
Install Python and PIP:
Install BigQuery API:
Set the GOOGLE_APPLICATION_CREDENTIALS environment variable.
Write a Python scipt to test the BigQuery API Connection:
Run the Python Script:
If the connection is successful, you should see "Connected" printed in the terminal output.
You are connecting to an App Service running on your Azure infrastructure from your DevBox.
Azure App Service enables you to build and host web apps, mobile backends, and RESTful APIs in the programming language of your choice without managing infrastructure. This connection between the app service and workspace would occur by setting up a bastion host that advertises the private routes to your DevZero network so you can access the private service through network tunneling. You must also set up a DNS Private Resolver to access the App Service's Private Endpoint from your DevBox.
Before you begin, follow the Connecting to Azure guide to set up the Bastion Host to access your private Azure services.
Following the above criteria, follow the Setting up DNS Private Resolver guide to access the DNS Private Zones.
To connect to an App Service running in the private subnet, please ensure it is within the same Resource Group and VNET containing the Bastion Host.
It would be best if you created a workspace so you can access the app service:
Go to DevZero Dashboard.
Navigate to the Workspaces tab and click on New workspace.
Enter the workspace name and click on Select from recipe library.
Click on New Recipe and enter the recipe name and click on Create a recipe.
Select a workspace region and click on Launch.
Navigate to Networking and open Private Endpoints page.
Click on Add > Express and then enter the name of your private endpoint.
Then select the VNET and a compatible subnet. Turn on the Integrate with private DNS zone option.
Click on Ok, and your private connection to your web app will be successfully deployed.
Follow the Below steps to access your Web App from your DevBox :
Connect to the workspace using the following command:
Copy the Default domain of the App Service you want to access.
Connect to the App Service:
If you need to make a new App Service running in a private subnet and access it through DevZero's network, then follow the below steps:
Go to Home > App Services and click on Create > Web App.
In the Basics section, select the resource group you previously selected for your VNET.
Enter the Name of the web app, choose the Publishing Model between Code, Container.
Select your Runtime Stack, Operating System, Region and then configure your Pricing Plans accordingly.
On the Container page, select your desired Image source from Quickstart images, Azure Container Registry, or Another registry.
For this guide, we will be working with Quickstart images. Then select or input the Image for your container.
In the Networking section, choose the off option under the Enable public access section.
Click on Review + Create and then click on Create.
After deploying the app, open your created service and navigate to Deployment > Deployment Center.
Select a Code Source and then enter the Organisation, Repository, and branch name. After you are done with your configuration, click on Save.
Navigate to Networking and open Private Endpoints page.
Click on Add > Express and then enter the name of your private endpoint.
Then select the VNET and a compatible subnet. Turn on the Integrate with private DNS zone option.
Click on Ok, and your private connection for your web app will be successfully deployed.
Select your Operating System, Region and then configure your Pricing Plans accordingly.
On the Deployment page, choose whether you want to enable Continuous deployment. If enabled, Enter your GitHub Repository details for your source code, such as the Organization, Repository, and Branch names.
In the Networking section, choose the off option under the Enable public access section.
Click on Review + Create and then click on Create.
After creating the web app, navigate to Networking and open the Private Endpoints page.
Click on Add > Express and then enter the name of your private endpoint.
Then select the VNET and a compatible subnet. Turn on the Integrate with private DNS zone option.
Click on Ok, and your private connection for your web app will be successfully deployed.
If you need to make a new static web App Service, then follow the below steps:
Go to Home > App Services and click on Create > Static Web App.
In the Basics section, select the resource group you previously selected for your VNET.
Enter the Web App name, and Hosting plan.
After this, choose the Source Model between GitHub, Azure Devops or Other.
Enter the Organisation, Repository, and branch name.
Click on Review + Create and click on Create.
Navigate to Networking and open Private Endpoints page.
Click on Add > Express and then enter the name of your private endpoint.
Then select the VNET and a compatible subnet. Turn on the Integrate with private DNS zone option.
Click on Ok, and your private connection for your web app will be successfully deployed.
Enter the Organisation, Project, Repository, and branch name.
Click on Review + Create and click on Create.
Navigate to Networking and open Private Endpoints page.
Click on Add > Express and then enter the name of your private endpoint.
Then select the VNET and a compatible subnet. Turn on the Integrate with private DNS zone option.
Click on Ok, and your private connection for your web app will be successfully deployed.
If you need to make a new App Service with database integration, then follow the below steps:
Go to Home > App Services and click on Create > Web App + Database.
In the Basics section, select the resource group you previously selected for your VNET.
Enter the Web App name, and Runtime stack.
After this, select the database Engine, Server name, and Database name.
If you want to, select the Azure Cache for Redis option and choose your Hosting plan.
Click on Review + Create and click on Create.
After deploying the app, open your created service and navigate to Deployment > Deployment Center.
Select a Code Source and then enter the Organisation, Repository, and branch name. After you are done with your configuration, click on Save.
Navigate to Networking and open Private Endpoints page.
Click on Add > Express and then enter the name of your private endpoint.
Then select the VNET and a compatible subnet. Turn on the Integrate with private DNS zone option.
Click on Ok, and your private connection for your web app will be successfully deployed.
It would be best if you created a workspace so you can access the app service:
Go to DevZero Dashboard.
Navigate to the Workspaces tab and click on New workspace.
Enter the workspace name and click on Select from recipe library.
Click on New Recipe and enter the recipe name and click on Create a recipe.
Select a workspace region and click on Launch.
Follow the Below steps to access your Web App from your DevBox :
Connect to the workspace using the following command:
Copy the Default domain of the App Service you want to access.
Connect to the App Service:
Connecting to GCP Cloud Storage Service from your DevBox.
Go to your DevBox and install Gcloud SDK:
Authenticate your GCP account with Gcloud SDK:
Access your cloud storage list by:
Go to Cloud Storage > Buckets.
Click on Create.
Enter a unique name for the bucket and click on Create.
Go to your DevBox and install Gcloud SDK:
Authenticate your GCP account with Gcloud SDK:
Access your cloud storage list by:
Connecting to an Cloud SQL running in the private subnet of GCP VPC to your DevBox.
Follow the Connecting to GCP guide.
Go to Cloud SQL > Instances and note down the Internal IP Address of the instance.
Go to VPC network > Routes and select the region where you have deployed the instance.
Copy the Destination IP Range of the Peering Subnet route which contains the IP address of the Cloud SQL Instance.
SSH into your Bastion Host and enter the following command:
Go to DevBox.
Connecting to the Database.
Run the following commands:
To install the mysql client cli:
To access the database:
To install the psql client cli:
To access the database:
Go to Cloud SQL > Create an instance.
Use one of the database Engine in the Configuration.
Choose the Available Versions of the Database.
Enter your Instance ID and Password.
Go to Choose region and zonal availability and select the zone where you have provisioned your Private Subnet.
Scroll down to Customize your instance > Connections and choose Private IP only.
Enter your VPC when prompted.
Click on create a private service access connection and select Use automatically assigned IP range while choosing Allocated IP range.
Click on Create Instance.
Go to Cloud SQL > Instances and note down the Internal IP Address of the instance.
Go to VPC network > Routes and select the region where you have deployed the instance.
Copy the Destination IP Range of the Peering Subnet route which contains the IP address of the Cloud SQL Instance.
SSH into your Bastion Host and enter the following command:
Go to DevBox.
Connecting to the Database.
Run the following commands:
To install the mysql client cli:
To access the database:
To install the psql client cli:
To access the database:
Connecting to an Firestore instance to your DevBox.
Follow the Connecting to GCP guide.
Connect to your DevZero workspace.
Store the Google Authentication Credentials on the workspace.
Install Python and PIP:
Install Firestore Admin API:
Set the GOOGLE_APPLICATION_CREDENTIALS environment variable.
Write a Python scipt to test the Firestore Admin API Connection:
Run the Python Script:
If the connection is successful, you should see "Connected" printed in the terminal output.
Go to Firestore > Databases and click on Create database.
Choose the Datastore Mode and click on Continue.
Enter your Database ID and select the between Region and Multi-region mode.
Choose your desired region and click on Create Database.
Connect to your DevZero workspace.
Store the Google Authentication Credentials on the workspace.
Install Python and PIP:
Install Firestore Admin API:
Set the GOOGLE_APPLICATION_CREDENTIALS environment variable.
Write a Python scipt to test the Firestore Admin API Connection:
Run the Python Script:
If the connection is successful, you should see "Connected" printed in the terminal output.
Connecting to Memorystore running in the private subnet of GCP VPC from your DevBox.
Follow Connecting to GCP guide.
Go to Memorystore > Clusters.
Select your Instance and copy your Domain Endpoint.
Go to your DevBox and connect to Service:
Go to Memorystore > Clusters and click on Create Instance.
Enter the Cluster ID and choose the region.
Choose the Node type, Cluster Size and Replicas.
Choose the VPC Network under the Set up connection section.
Setup the service connection policy if prompted.
Fill in the network name and the private subnet in the policy section.
After setting up the connection policy, click on Create Cluster.
Go to Memorystore > Clusters.
Select your Instance and copy your Domain Endpoint.
Go to your DevBox and connect to Service:
Connecting to GCP Kubernetes Cluster running in the private subnet of GCP VPC from your DevBox.
Follow Connecting to GCP guide.
Go to your DevBox and install Gcloud SDK:
Authenticate your GCP account with Gcloud SDK:
Download the kubectl binaries:
Install kubectl:
Connect to the cluster:
Check if the cluster is accessible:
Go to Kubernetes Engine > Kubernetes Cluster > Create.
Select the standard Cluster, enter the name of the cluster and assign a Regional location where your Private Subnet is located.
Click on Next. In the Node Pool > Default Pool > Nodes > Configure node settings section, choose the desired Machine Configuration for the nodes.
Go to Cluster > Networking and select the Network VPC along with the Private Subnet for the cluster. Choose Private cluster in the IPv4 network access and uncheck the Access control plane using its external IP address checkbox.
Enter a desired Default pod address range and service address range. Here we have taken 192.168.0.0/16 and 192.169.0.0/16 for pod address range and service address range repectively.
Enter the Bastion Host's CIDR Range in the Authorized Networks section.
Click on Create.
Go to your DevBox and install Gcloud SDK:
Authenticate your GCP account with Gcloud SDK:
Download kubectl binaries:
Install kubectl:
Connect to the cluster:
Check if the cluster is accessible:
Connecting to GCP Cloud Run Service from your DevBox.
If you have an existing Cloud Run Container deployed, follow the steps below to access its content from the DevBox. Ensure the Cloud Run Deployment has the Require authentication
option selected in the Security section.
First, we need to create a recipe for the workspace:
Enter the recipe name and click on Create a recipe.
Now use the below-provided snippet to create a recipe for your workspace:
Click on Save and Build and when the build is successful, click on Publish.
Enter the workspace name and click on Select from recipe library.
Select the recipe you just created above and click on Select.
Click on Launch, and your workspace will be ready shortly.
Now, this is where the real task begins. After downloading the gcloud
package, we must authenticate with our Google Cloud account. To do this, we need to run the simple command.
After running the command, you will be given various options for choosing your Google account, default Project, and default Compute Region and Zone. You can choose what you prefer.
To access your Cloud Run container privately, you need to send a GET
request with an authentication token.
Follow the below steps to generate the Authentication token and access the Cloud Run application:
Use the below command to get the token:
Export the token to an environmental variable:
Now that everything is set, we can finally finish this all off by accessing the applications with the curl
command:
If you want to create a new Cloud Run Container, you can follow the below steps.
Go to Cloud Run > Services and click Deploy Container.
Choose a deployment method between Deploy one revision from an existing container image, Continuously deploy from a repository (source or function).
We are creating a container with an existing demo image for this guide.
Enter your Container Image URL or select by clicking on Select.
Click on Set Up with Cloud Build and follow the instructions.
Then Enter your Service Name and Region of deployment.
Select Require authentication option in the Authentication section.
Leave the remaining configurations as default and click on Create.
First, we need to create a recipe for the workspace:
Enter the recipe name and click on Create a recipe.
Now use the below-provided snippet to create a recipe for your workspace:
Click on Save and Build and when the build is successful, click on Publish.
Enter the workspace name and click on Select from recipe library.
Select the recipe you just created above and click on Select.
Click on Launch, and your workspace will be ready shortly.
Now, this is where the real task begins. After downloading the gcloud
package, we must authenticate with our Google Cloud account. To do this, we need to run the simple command.
After running the command, you will be given various options for choosing your Google account, default Project, and default Compute Region and Zone. You can choose what you prefer.
To access your Cloud Run container privately, you must send a GET
request with an authentication token.
Follow the below steps to generate the Authentication token and access the Cloud Run application:
Use the below command to get the token:
Export the token to an environmental variable:
Now that everything is set, we can finally finish this all off by accessing the applications with the curl
command:
Learn how to connect to GCP resources privately from a DevBox.
Go to VPC Network > VPC Networks.
Select Create VPC Network.
Enter VPC name, and under Subnets choose region, IP Stack option and IP CIDR range. Remember to select On option for Private Google Access while creating the private subnet.
Here we are using 10.0.1.0/24 for public subnet range and 10.0.2.0/24 for private subnet range. Customize the IPv4 CIDR block if needed.
Click on Create and it will generate the VPC Network for you.
After the VPC network creation, go to VPC-Name > Firewalls. Select Add Firewall Rule and then enter the rule name, and source IP range (Source = 0.0.0.0/0).
After that you will be asked to select the ingress ports and protocols. Allow inbound SSH (Port range = 22). We’ll need this during initial setup but can close the firewall later.
Go to Compute Engine > Create an Instance > Advanced Options > Networking section.
Add the respective firewall tags in the Network Tags box.
Attach public subnet to the instance from the VPC and assign it a public IP Address.
SSH into the machine and Install the DevZero CLI from the script:
Log into your account by executing:
Enable IP forwarding to access resources on VPC CIDR:
Connect to DevZero network:
Verify that the machine is connected to your DevZero network:
You should see the GCP virtual machine hostname.
Now you will be able to access Private GCP Resources from your DevBox.
You are connecting to a GCP Secret Manager from your DevBox.
Here, you will connect to a GCP Secret Manager from your DevBox. This can be done using any programming language API, but for the scope of this document, we will use Python.
To connect to an existing Secret Manager, Follow the below steps:
To make the connection, you need to set up the IAM service account.
Go to IAM & Admin > Service Accounts* and click on Create Service Account.
Enter the Service Account Name and click on Create and Continue.
Click on Select a role, select Secret Manager Admin
, and click on Continue.
Select the new service account and go to the Keys tab.
Click on Add Key > Create a new key and click on Create.
Now, to retrieve the value from the secrets using the API, you need to authenticate the gcloud
CLI and verify the process with the access key we just downloaded by following the below steps:
Go to DevBox and store the Google Authentication Credentials on the workspace.
Install Python and PIP:
Install Secret Manager API:
Set the GOOGLE_APPLICATION_CREDENTIALS environment variable by using the following command:
Write a Python script to test the Secret Manager API Connection:
Run the Python Script:
If the connection is successful, you should see Secret printed in the terminal output.
If you need to make a new Secret Manager and access it through DevBox, then follow the below steps:
Go to Security > Secret Manager and click on Create Secret.
Enter the Name of the secret and then either upload your Secret or enter it within the box provided.
If you are storing an API Key secret, then it is advisable to check the box for Set rotation period under the Rotation section.
To make the connection, you need to set up the IAM service account.
Go to IAM & Admin > Service Accounts* and click on Create Service Account.
enter the Service Account Name and click on Create and Continue.
Click on Select a role, select Secret Manager Admin
, and click on Continue.
Select the new service account and go to the Keys tab.
Click on Add Key > Create a new key and click on Create.
Now, to retrieve the value from the secrets using the API, you need to authenticate the gcloud
CLI and verify the process with the access key we just downloaded by the below steps:
Go to DevBox and store the Google Authentication Credentials in the workspace.
Install Python and Pip:
Install Secret Manager package:
Set the GOOGLE_APPLICATION_CREDENTIALS environment variable by using the following command:
Write a Python script to test the Secret Manager API Connection:
Run the Python Script:
If the connection is successful, you should see Secret printed in the terminal output.
Connecting to an Firestore instance to your DevBox.
Connect to your DevZero workspace.
Store the Google Authentication Credentials on the workspace.
Install Python and PIP:
Install Firestore Admin API:
Set the GOOGLE_APPLICATION_CREDENTIALS environment variable.
Write a Python scipt to test the Firestore Admin API Connection:
Run the Python Script:
If the connection is successful, you should see "Connected" printed in the terminal output.
Go to Firestore > Databases and click on Create database.
Choose the Native Mode and click on Continue.
Enter your Database ID and select the between Region and Multi-region mode.
Choose your desired region and click on Create Database.
Connect to your DevZero workspace.
Store the Google Authentication Credentials on the workspace.
Install Python and PIP:
Install Firestore Admin API:
Set the GOOGLE_APPLICATION_CREDENTIALS environment variable.
Write a Python scipt to test the Firestore Admin API Connection:
Run the Python Script:
If the connection is successful, you should see "Connected" printed in the terminal output.
Learn how to connect to AWS resources privately from a DevBox.
If you're more of a visual learner, check out the !
Go to VPC > Your VPCs > Create VPC.
Select VPC and more.
Enter a tag name to auto-generate VPC and Subnet Names. Customize the IPv4 CIDR block if needed.
Select "In 1 AZ" in the NAT Gateways section.
Use one of the .
In the Network Settings, edit the VPC to assign the one you created above.
Assign the instance to a public subnet of the VPC, and assign it a public IP address.
In the security groups configuration, edit the Security Group to allow inbound ssh (Port range = 22, Source = 0.0.0.0/0). We’ll need this during initial setup but can close the firewall later.
SSH into the machine and Install the DevZero CLI from the script:
Log into your account by executing:
Enable IP forwarding to access resources on private subnets:
Connect to DevZero network:
Verify that the machine is connected to your DevZero network:
You should see the EC2 machine hostname.
You should now be able to ping or ssh private AWS resources from your DevBox:
Coming soon...
Need help? Reach out to
Need help? Reach out to
Need help? Reach out to
is a serverless service offered by GCP to manage a computing platform that enables you to run invocable containers via requests or events. In this, we will set up a pipeline for our project within DevBox; it will be routed through Cloud Run. Then, depending on the type of project, we can either access it through the web or through the internal VPC of Google Cloud Infrastructure.
Go to the and click on New recipe.
Go to the by clicking New workspace.
Go to the and click on New recipe.
Go to the by clicking New workspace.
Use one of the .
Follow the guide.
Looking for a pre-made recipe template? See: Bazel Buildfarm
Make sure both kubectl and helm are installed.
Install bazel buildfarm on your k8s cluster using the official helm chart:
Forward the port from the k8s cluster to your DevBox:
Create the following bazel workspace file structure for testing:
main.cc
BUILD
WORKSPACE
Leave this file empty.
Run bazel run :main
to verify the build locally.
DOCKER_HOST
Create a new workspace with Docker installed (How-to).
Make sure you are connected to the DevZero network:
Set DOCKER_HOST
environment variable on your machine to match the DevBox hostname:
Verify the installation by running:
When you run the docker build
command, the build context will be sent to the DevBox and the build process will run.
If you're seeing "Host key verification failed" error, try connecting to your DevBox via ssh first to verify the fingerprint.
Create a new workspace with Docker installed (How-to).
Inside your DevBox, run the BuildKit container:
See Remote driver docs for all available options.
On your machine, create a new buildx instance:
Build an image using remote driver (and download it locally):
Create a new workspace with Docker installed (How-to).
Inside your DevBox, install the Docker Registry:
See CNCF Distribution guide for available options.
Make sure your machine is connected to the DevZero network:
Verify you can access the registry from your machine:
Build and push your image to the registry
With Docker:
With BuildKit remote cache (see previous section):
Verify the image is available in the registry:\
If you're getting "http: server gave HTTP response to HTTPS client", try adding the following to your Docker daemon json configuration:
The following guide outlines how to use DevBox as a runtime for GitHub actions.
Pre-built recipe templates are available here.
Launch a new workspace on DevZero
Visit your GitHub organization/repo settings page.
Go to Actions > Runners.
For organization-wide runners: https://github.com/organizations/ORGANIZATION/settings/actions/runners
For repository-wide runners: https://github.com/ORGANIZATION/REPO/settings/actions/runners
Click on "New runner" and select "New self-hosted runner".
Select "Linux" and set "x64" as architecture.
Follow the instructions from GitHub provided on the page, which are similar to:
The $TOKEN_FROM_GITHUB will be in the UI when you create the new runner.
You may use the default settings or customize values as you'd like when going through the prompts
The token from GitHub wll expire in about an hour and is unique for your instance.
You can also get the registration token non-interactively by sending a http request using curl:
Verify that the runner was added to your repo/org and is either in "Idle" or "Online" state.
Tip: The runner name should be same as the DevBox hostname.
Run a GitHub Action on the self-hosted runner to verify that it passes successfully, set runs-on: self-hosted
:
Here's a five minute video to see the process from end to end.
The Actions Runner Controller setup is still in beta and some actions, like running Docker in tests, aren't yet supported.
You will need a Personal Access Token (PAT).
To create one:
Visit Profile > Developer Settings > Personal access tokens > Tokens (classic).
Click on "Generate new token", select "Generate new token (classic)".
In the "scopes" section, select repo
and optionally admin:org
for organization runners.
Copy your new Personal Access Token.
After you obtained the PAT:
Install GitHub Actions Runner Controller using helm.
Adjust the NAMESPACE
variable as needed.
Adjust the INSTALLATION_NAME
, NAMESPACE
, GITHUB_CONFIG_URL
, and GITHUB_PAT
variables as needed.
Visit your repository/org settings, select Actions > Runners. Your new runner-set should be listed under "Runner scale sets" with the status shown as "Online".
To verify the installation, run a sample action:
Comprehensive guide for connecting to a Supabase Project from your DevBox.
If you're more of a visual learner, check out the video tutorial!
Here, you will connect to a Supabase Project from your DevBox. This would be done by setting up the cluster in your Project dashboard and accessing it through psql
client tool.
Before you begin, you should create your account with Supabase and create a new organisation.
Now we need to install the Postgres psql
client tool.
Follow the below steps to do so:
Use the following command to reload the local package database:
Install the PostgresSQL :
To make the connection, follow the below steps:
Go to Supabase Dashboard.
Open the project which you want to access through the DevBox.
Click on connect and copy the connection string for PSQL
.
Now in your DevBox, simply paste the connection string and enter the password when prompted.
If you need to make a new Supabase database and access it through DevBox, then follow the below steps:
Go to Supabase Dashboard.
Click on New Project and enter the Organisation, Project name and a strong Database Password.
Choose your region and click on Create new project.
Give it a few moments and your project will be ready to use.
Now we need to install the Postgres psql
client tool.
Follow the below steps to do so:
Use the following command to reload the local package database:
Install the PostgresSQL :
To make the connection, follow the below steps:
Go to Supabase Dashboard.
Open the project which you want to access through the DevBox.
Click on connect and copy the connection string for PSQL
.
Now in your DevBox, simply paste the connection string and enter the password when prompted.
Comprehensive guide for connecting to a MongoDB Cluster from your DevBox.
This would be done by setting up the cluster in your Atlas dashboard through one of 3 available cloud providers (AWS, Azure, or GCP) and accessing it through DevBox.
Before you begin, create your account with MongoDB.
MongoDB only supports Private Endpoint access for Dedicated or Serverless clusters. Private Endpoint access for the Shared cluster is not yet supported.
To connect to a database cluster, you must create a private endpoint with one of MongoDB's three supported cloud providers (AWS, GCP, Azure).
To check and configure the same, follow the below steps:
Go to MongoDB Atlas.
Go to Security > Network Access and open the Private Endpoint tab.
Click on Add Private Endpoint and choose your cloud provider. For this tutorial, we will be using Azure.
You must provide the billing information in the Edit Payment Method form if you still need to get the payment method configured for your organization.
Click on Next and choose the Region where you want to deploy your endpoint.
Enter your Resource Group Name, Virtual Network Name, Subnet Name, and the name you want to give to your endpoint.
Copy and run this PrivateLink Endpoint Command where your Azure CLI is configured. Remember that you can only copy the command once Atlas finishes creating VNET resources in the background for internal use.
After creating the private endpoint, copy the Private Endpoint Resource ID and Private Endpoint IP Address and paste them into the MongoDB Private Endpoint Dialog box.
Click on Create, and your private endpoint will be created.
We need to install the mongosh
shell tool to connect with the cluster.
Follow the below steps to do so:
Install gnupg
and curl
if they are not already:
Get the MongoDB public GPG key:
Create a list file for MongoDB:
Install the MongoDB Package:
verify if mongosh
is installed or not:
To connect to the MongoDB cluster, follow the below steps:
Go to MongoDB Atlas.
Go to Database > Clusters and select the Cluster you want to access.
Click on Connect and choose the private endpoint option.
Then Click on Shell, copy the connection string, and paste it into your DevBox:
Enter the password when prompted, and you will see the MongoDB cluster is connected.
If you need to make a new database cluster and access it through DevBox, then follow the below steps:
Go to MongoDB Atlas.
Go to Database > Clusters and click on Create.
Choose between Dedicated or Serverless database cluster type.
Enter the Instance name, Provider, and Region.
Click on Create Deployment and give it time to deploy the infrastructure.
Go to Security > Network Access and open the Private Endpoint tab.
Click on Add Private Endpoint and choose your cloud provider. For this tutorial, we will be using Azure.
You must provide the billing information in the Edit Payment Method form if you don't have a payment method already configured for your organization.
Click on Next and choose the Region where you want to deploy your endpoint.
Enter your Resource Group Name, Virtual Network Name, Subnet Name, and the name you want to give to your endpoint.
Copy and run this PrivateLink Endpoint Command where your Azure CLI is configured. Remember that you can only copy the command once Atlas finishes creating VNET resources in the background for internal use.
Copy the Private Endpoint Resource ID and Private Endpoint IP Address and paste them into the MongoDB Private Endpoint Dialog box after creating the private endpoint.
Click on Create, and your private endpoint will be created.
To connect with the cluster, we need to install the mongosh
shell tool.
Follow the below steps to do so:
Install gnupg
and curl
if they are not already:
Get the MongoDB public GPG key:
Create a list file for MongoDB:
Install the MongoDB Package:
verify if mongosh
is installed or not:
To connect to the MongoDB cluster, follow the below steps:
Go to MongoDB Atlas.
Go to Database > Clusters and select the cluster you want to connect to.
Click on Connect and choose the private endpoint option.
Then Click on Shell, copy the connection string, and paste it into your DevBox CLI:
Enter the password when prompted, and you will see the mongosh shell if the connection is authenticated.
Comprehensive guide for connecting to a PlanetScale Database from your DevBox.
If you're more of a visual learner, check out the video tutorial!
PlanetScale is a MySQL based database service which is built on Vitess and unlocks performance, scalability, and cost optimization for hyperscale databases through horizontal sharding. In this guide, we will walk you through the entire process of connecting your PlanetScale Database to your DevBox.
Before you begin, create your account with PlanetScale.
Follow the below steps to generate the connection string for database:
Go to PlanetScale Dashboard.
Click on the database you want to access.
Click on Connect and click on Create password.
Note down the Username and Password generated as it would not be displayed again.
In the Select your language or framework choose the language or framework you want to connect your database with. For this guide, we will be going with MySQL CLI.
Note down the connection string.
You will need to create a Recipe in DevZero equipped with the necessary tools like mysql
:
Go to DevZero Dashboard and open the Recipes tab.
Click on New Recipe and enter the recipe's name.
Click on Create a recipe, and your recipe will be created.
Replace the recipe yaml file with the snippet below. Remember to replace the placeholder username and password with the value you noted down in the above steps:
After editing the recipe, click on Save and Build.
When the build is successful, click on Publish.
After the recipe is published, click on Launch and create a new workspace by providing a Workspace Name.
Click on Launch and your workspace will be created.
Now, with everything set, you just need to use the connection string to access the database:
Go to DevBox.
Use the following command to connect to the database:
If you need to make a new PlanetScale database and access it through DevBox, then follow the below steps:
Go to PlanetScale Dashboard.
Click on Create a new database and enter the Name and Region of your database instance.
Then choose the Cluster size and Autoscaling storage and click on Create database.
Enter the Password name when prompted.
A Username and Password would be generated for you. Note down the password as it would not be displayed again.
In the Select your language or framework choose the language or framework you want to connect your database with. For this guide, we will be going with MySQL CLI.
Note down the connection string.
You will need to create a Recipe in DevZero equipped with the necessary tools like mysql
:
Go to DevZero Dashboard and open the Recipes tab.
Click on New Recipe and enter the recipe's name.
Click on Create a recipe, and your recipe will be created.
Replace the recipe yaml file with the snippet below. Remember to replace the placeholder username and password with the value you noted down in the above steps:
After editing the recipe, click on Save and Build.
When the build is successful, click on Publish.
After the recipe is published, click on Launch and create a new workspace by providing a Workspace Name.
Click on Launch and your workspace will be created.
Now, with everything set, you just need to use the connection string to access the database:
Go to DevBox.
Use the following command to connect to the database:
Comprehensive guide for connecting to a Timescale Database from your DevBox.
Timescale is an open-source time-series SQL database optimized for fast ingest and complex queries. In this guide, we will walk you through the entire process of connecting your Timescale Database to your DevBox step by step.
Before you begin, create your account with Timescale and create a new organization.
Follow the Connecting to AWS guide to set up the advertise routes for DevBox to access AWS Services. This is necessary since we will use a VPC peering with a timescale database service for a secure connection.
You will need to create a Recipe in DevZero equipped with the necessary tools like psql
:
Go to DevZero Dashboard and open the Recipes tab.
Click on New Recipe and enter the recipe's name.
Click on Create a recipe, and your recipe will be created.
Replace the recipe yaml file with the snippet below:
After editing the recipe, click on Save and Build.
When the build is successful, click on Publish.
After the recipe is published, click on Launch and create a new workspace by providing a Workspace Name.
Click on Launch and your workspace will be created.
To make your connection secure, we need to create a VPC within the Timescale Infrastructure and then peer it to the AWS VPC:
Go to Timescale Dashboard > VPC.
Click on New VPC and enter the Region, Name and IP Range of the VPC.
Click on Create and after creation, click on Add under VPC Peering column.
Enter your AWS VPC details and click on Add connection.
Follow the below steps to connect to the database instance:
Click on the Service you want to access.
Click the Triple dot dialog menu in the top right corner.
Choose the Change service environment option and go to the VPC tab.
Select the VPC and click on Attach VPC.
Now, with everything set, you just need to use the connection string to access the database:
Click on the Service you want to access.
Scroll down and copy the connection string you see.
Go to DevBox, paste the connection string, and enter the password when prompted:
If you need to make a new Timescale database and access it through DevBox, then follow the below steps:
To make your connection secure, we need to create a VPC within the Timescale Infrastructure and then peer it to the AWS VPC:
Go to Timescale Dashboard > VPC.
Click on New VPC and enter the Region, Name and IP Range of the VPC.
Click on Create, and after creation, click on Add under the VPC Peering column.
Enter your AWS VPC details and click on Add connection.
Click on New Service and pick your service type between Time Series and Analytics and Dynamic PostgreSQL.
Choose the Region, Compute configuration, and Environment type.
In the VPC section choose the vpc you justv created.
Click on Create Service and your database service will be created.
You will need to create a Recipe in DevZero equipped with the necessary tools like psql
:
Go to DevZero Dashboard and open the Recipes tab.
Click on New Recipe and enter the recipe's name.
Click on Create a recipe, and your recipe will be created.
Replace the recipe yaml file with the snippet below:
After editing the recipe, click on Save and Build.
When the build is successful, click on Publish.
After the recipe is published, click on Launch and create a new workspace by providing a Workspace Name.
Click on Launch, and your workspace will be created.
Now, with everything set, you just need to use the connection string to access the database:
Click on the Service you want to access.
Scroll down and copy the connection string you see.
Go to DevBox, paste the connection string, and enter the password when prompted.
Coming soon...
Need help? Reach out to
Using a NeonDB database branch from a DevZero workspace.
Go to Your Project > Project Dashboard.
Click on Branch , create a new branch.
Give it a name and select Current point in time to create the branch off the current state of your main database.
install linux helper packages
clone repo
install nodejs
run npm install
npm start
: to start the application
We will be implementing the above steps using the recipe file below
The Recipe page has some helper snippet to guide you in generating such files
You can access your DevBox interactively using Remote Desktop.
Create a new workspace with Docker installed ().
Launch the headless VNC docker environment:
See how to connect below.
More information about the Docker image .
Make sure the package repositories are up-to-date:
Install Xfce Desktop Environment:
Install a VNC server:
Create a new file in ~/.vnc/xstartup
:
Start the VNC server:
You will be prompted to create a password.
Make sure your machine is connected to the DevZero network before connecting
You can connect to the remote desktop using the VNC protocol.
On macOS, open "Finder" > "Go" > "Connect to server". Type in the server address above and click on "Connect", if promted, enter the password you've selected.
For the Docker-based install, the default password is vncpassword
Basic knowledge of and
Once the branch is created, please copy the connection string and add it to your . In this guide, it is saved as DATABASE_URL
.
For the purpose of this guide, we will be using a built with nextjs that requires an environment variable called DATABASE_URL
. We will be creating a recipe for this application and we will launch a workspace based on it.
run npm run build
: in this step, we need the database URL to be present so we can run some commands that are required for manipulating the database
When asked for repository, feel free to use or create a fork of it if you want to follow this guide.
Now that we have a working recipe, we can create a workspace off it from the by clicking launch.
Connecting to an Azure Table Storage from your DevBox.
Here, you will connect to a Table Storage from your DevBox. This would be done by setting up a bastion host that advertises the private routes to your DevZero network so that you can access the private service through network tunneling. You must also set up a DNS Private Resolver to access the Table Storage's Private Endpoint from your DevBox.
Before you begin, follow the Connecting to Azure guide to set up the Bastion Host to access your private Azure services.
Following the above criteria, follow the Setting up DNS Private Resolver guide to access the DNS Private Zones.
After successfully setting up the DNS Private Resolver, follow the Configuring Storage Account guide to access the storage account endpoint.
To connect to a Storage Account, ensure it is within the same Resource Group containing the Bastion Host.
Now follow the below steps to access the Table Storage on your DevBox:
Go to DevBox and install the Azure CLI tool using the following command:
Login into your Azure account using the login
command:
After you have completed your authentication, go to Home > Storage Accounts and select your storage account.
Then go to the Security + Networking > Access Keys section and note down either of the two access keys presented to you.
After you have acquired the access key, you may use the following command to Check existence and List the available tables:
To check the Existence of the table, use the following command:
To List all the available tables, use the following command:
If you need to make a new Table Storage and access it through DevBox, then follow the below steps:
Firstly, you must follow the Configuring Storage Account guide to create and configure a new storage account. After the setup, you must also set up the DNS Private Resolver by following the Setting up DNS Private Resolver guide.
After the above mentioned steps are completed, you may go ahead and create a container for Blob Storage by following these steps:
Go to Home > Storage Accounts and click on your storage account.
Go to the Data Storage tab and click on Tables.
Create a new Table by entering the table name and clicking on Create.
After creating the table, go to the Security + Networking > Access Keys section and note down either access key.
After creating the table, you must install and authenticate your Azure CLI to easily access Blob Storage. To do so, you may follow the below steps:
Go to DevBox and install the Azure CLI tool using the following command:
Login into your Azure account using the login
command:
You may use the following command to Check existence and List the available tables:
To check the Existence of the table, use the following command:
To List all the available tables, use the following command:
Configuring the Azure Storage Account to access its endpoint from DevBox.
Here, you will configure a Storage Account to access it from your DevBox. This would be done by setting up a bastion host that advertises the private routes to your DevZero network so that you can access the private service through network tunneling. You would also need to set up a DNS Private Resolver to access the Storage Account's Private Endpoint from your DevBox.
Before you begin, follow the Connecting to Azure guide to set up the Bastion Host to access your private Azure services.
To configure a Storage Account, ensure it is within the same Resource Group containing the Bastion Host.
Following the above criteria, follow the Setting up DNS Private Resolver guide to access the DNS Private Zones.
Now follow the below steps to configure the Storage Account:
Go to Home > Storage Accounts and click on the Storage Account you want to access through the private endpoint.
Go to Networking > Firewalls and virtual networks tab in the Security + Networking section and under Public network access
choose the Disabled
option. Click on Save. This will make your storage account completely private.
After that, go to Networking > Private endpoint connections and click on Private endpoint.
Choose your Resource group and enter the instance name.
Click Resource and select your desired Target sub-resource
for your private endpoint. Remember that if you have more than one sub-resource type, you need to create a separate endpoint for each one.
Click on Virtual Network and select your Virtual Network (VNET), which houses the bastion host and DNS Private Resolver.
Select a compatible subnet, then click on Next, and leave the rest of the settings as default.
Click on Create, and your Private Endpoint will be created.
To verify if you can access the storage account endpoint from your DevBox, just use the following command in your DevBox:
If you need to make a new Storage Account and access it through DevBox, then follow the below steps:
Go to Home > Storage Accounts and click on Create.
In the Basics section, select the resource group you previously selected for your VNET.
Then, input your account name, region, and desired performance type.
Go to the Networking section and choose Disable public access and use private access
option in Network access.
Click on Add private endpoint and enter the Name, **Storage sub-resource type.
In the Networking section, select the VNET which houses the bastion host.
Select a compatible subnet and then choose your private DNS zone.
Click on OK and then click on Review + Create. Finally, click on Create.
If the above steps are completed, you must follow the Setting up DNS Private Resolver guide to access the DNS Private Zones.
To verify if you can access the Storage Account, follow the below steps:
Go to the DevBox.
Use the following command to see if the private endpoint is accessible to you:
Learn how to connect to Azure resources privately from a DevBox.
In this guide you will know how to setup a Bastion Host on Azure Infrastructure. This Bastion Host will allow you to connect to Private Azure services and use them directly from your DevBox.
If you're more of a visual learner, check out the video tutorial!
In this step, you will be creating a VNET. This will house all of your resources together including the bastion host.
Go to Home > Virtual Networks > Create Virtual Network.
Under the Basics section, enter the Resource group name.
you can select an existing Resource Group or create a new Resource Group by clicking on create new.
Enter the Virtual Network name and the desired region of deployment.
After setting up the Basics, navigate to the IP Addresses Section and create a Public subnet by entering the subnet name and Starting address of the subnet.
To make a private subnet in Azure, you just need to check the Enable private subnet (no default outbound access) checkbox under the Private Subnet section while creating the subnet.
After everything is setup, you can navigate to the Review + Create section and click on Create.
Now you need to create and setup a Virtual Machine which you would be using as the Bastion Host.
Go to Home > Virtual Machines > Create a virtual machine.
In the Basics section, choose the same resource group which you chose for your VNET.
Then input your VM name, region and image.
you can view the available VM images here.
Enter your desired username and select the allow selected ports for the Public inbound ports option.
Go to the Networking section and enter your Virtual Network (VNET). Remember to choose the public IP option as you need to configure this virutal machine to access private azure services.
Select the Basic option for NIC network security group, it would create a security group for you which allows port access for SSH.
Click on Review + Create and click on Create.
Download the SSH private key when prompted, this will help you SSH into the Bastion Host later on.
Now you just need to install DevZero CLI and enable IP forwarding to access the private resources.
SSH into your Bastion Host and install the DevZero CLI:
Log into your account by executing:
Enable IP forwarding to access resources on private subnets:
Now you need to advertise your VNET route to connect to DevZero network:
Verify that the machine is connected to your DevZero network:
You should see the Azure machine hostname.
You should now be able to ping or ssh private Azure resources from your DevBox:
Comprehensive guide for connecting to Xata Workspace Database from your DevBox.
If you're more of a visual learner, check out the video tutorial!
Xata is a serverless data platform for PostgreSQL that optimizes reliability, scalability, and developer experience. Xata provides features that make it easier to build modern applications, such as Branching, Zero-downtime schema migrations, File attachments, and more. In this guide, we will walk you through the entire process of connecting your Xata Database to your DevBox step by step.
Before you begin, create your account with Xata and create a new Workspace.
First, you need to get the API access key so that we can connect to the Database:
Go to Xata Account Settings.
In the Personal API keys section, click on Add a key and enter the name of the key.
Note down the secret API key.
You will need to create a Recipe in DevZero equipped with the necessary tools like psql and store your API keys as well:
Go to DevZero Dashboard and open the Recipes tab.
Click on New Recipe and enter the recipe's name.
Click on Create a recipe, and your recipe will be created.
Replace the recipe yaml
file with the snippet below. Remember to replace the placeholder API key with the key you noted down in the above steps:
After editing the recipe, click on Save and Build.
When the build is successful, click on Publish.
After the recipe is published, click on Launch and create a new workspace by providing a Workspace Name.
Click on Launch and your workspace will be created.
Follow the below steps to connect to the database instance:
Go to Xata Dashboard.
Open the Database that you want to access through DevBox.
Copy the connection string for PostgreSQL endpoint and then use the following command to connect to the Database:
If you need to make a new Xata database and access it through DevBox, then follow the below steps:
Go to Xata Dashboard.
If you haven't created a database, the dashboard will automatically prompt you to create one, but if you have completed the initial setup, you need to click on Add Database.
Enter the database Name, choose the Region and enable the Enable direct access to Postgres option.
Click on Create, and your Database will be created and shown on your dashboard.
First, you need to get the API access key so that we can connect to the Database:
Go to Xata Account Settings.
In the Personal API keys section, click on Add a key and enter the name of the key.
Note down the secret API key.
You will need to create a Recipe in DevZero equipped with the necessary tools like psql
and store your API keys as well:
Go to DevZero Dashboard and open the Recipes tab.
Click on New Recipe and enter the recipe's name.
Click on Create a recipe, and your recipe will be created.
Replace the recipe yaml
file with the snippet below. Remember to replace the placeholder API key with the Key you noted down in the above steps:
After editing the recipe, click on Save and Build.
When the build is successful, click on Publish.
After the recipe is published, click on Launch and create a new workspace by providing a Workspace Name.
Click on Launch and your workspace will be created.
Follow the below steps to connect to the database instance:
Go to Xata Dashboard.
Open the database which you want to access through the DevBox.
Copy the connection string for PostgreSQL endpoint and then use the following command to connect to the database:
First you need to get the API access key so that we can connect to the database:
Go to Xata Account Settings.
In the Personal API keys section, click on Add a key and enter the name of the key.
Note down the secret API key.
You will need to create a Recipe in DevZero equiped with the neccesary tools like node
, xata
and store your API keys as well:
Go to DevZero Dashboard and open the Recipes tab.
Click on New Recipe and enter the name of recipe.
Click on Create a recipe and your recipe will be created.
Replace the recipe yaml
file with the snippet below. Remember to replace the placeholder API key with the Key you noted down in the above steps:
After editing the recipe, click on Save and Build.
When the build is successful, click on Publish.
After the recipe is published, click on Launch and create a new workspace by providing a Workspace Name.
Click on Launch and your workspace will be created.
Follow the below steps to connect to the database instance:
Go to DevBox and use the following command to authenticate your xata account:
Choose the Use an existing API key
option while authenticating, and then hit Enter/Return with the API Key shown when prompted.
Use the following command for access the database through Xata shell:
Select the Workspace, Database and Branch when prompted.
If you need to make a new Xata database and access it through DevBox, then follow the below steps:
Go to Xata Dashboard.
If you haven't created a database, the dashboard will automatically prompt you to create one, but if you have completed the initial setup, you just need to click on Add database.
Enter the database Name, and choose the Region.
Click on Create and your Database will be created and will show up on your dashboard.
First, you need to get the API access key so that we can connect to the database:
Go to Xata Account Settings.
In the Personal API keys section, click on Add a key and enter the name of the key.
Note down the secret API key.
You will need to create a Recipe in DevZero equipped with the necessary tools like node
and xata
and store your API keys as well:
Go to DevZero Dashboard and open the Recipes tab.
Click on New Recipe and enter the recipe's name.
Click on Create a recipe, and your recipe will be created.
Replace the recipe yaml
file with the snippet below. Remember to replace the placeholder API key with the Key you noted down in the above steps:
After editing the recipe, click on Save and Build.
When the build is successful, click on Publish.
After the recipe is published, click on Launch and create a new workspace by providing a Workspace Name.
Click on Launch and your workspace will be created.
Follow the below steps to connect to the database instance:
Go to DevBox and use the following command to authenticate your Xata account:
Choose the Use an existing API key
option while authenticating and then hit Enter/Return without entering the API Key when prompted.
Use the following command to access Databasebase through the Xata shell:
Select the Workspace, Database and Branch when prompted.