This Week #1: Working in the Open

At jetpack.io we're big believers of Working In The Open.

Starting this week we want to give our users more insights into what we're working on by sharing weekly updates, highlighting some of the work that each of our team members have been doing. The biggest highlight this week is that we were selected by Forbes as one of the Top 100 Cloud Rising stars of 2023.

Daniel

Jetpack.io was selected by Forbes, as one of the Top 100 Cloud Rising Stars of 2023. The Rising Stars is a shortlist of the most innovative cloud companies, and we're very happy that Jetpack.io is part of that group.

On the engineering side I spent time researching how to evolve our cloud-based environments in a few different directions. Finally spent time with Mike and John discussing what features we want to prioritize in our upcoming cycles.

Lucille

This week was a whirlwind for me, involving work on the websites, CLI, and infrastructure:

Websites: Our key sites are jetpack.io , devbox.sh (cloud app), and nixhub.io (Nix package finder). Forbes mentioned us in top companies for 2023 – what a surprise! Anticipating a jetpack.io domain boost as a result. I started the work on Devbox templates, a repository of official projects for quick starts. I crafted a draft UI in our Remix app, and am planning to hook up data from Supabase DB next.

Devbox CLI: Testing an example NodeJS Devbox project in a Devbox Cloud VM with Mohsen exposed a slow devbox install (15 mins). It turns out that the node version in devbox.lock was not pre-built in the Nix cache. As a quick fix, I replaced it with one that has a pre-built binary. Unfortunately, this “pre-built” info isn’t available in Nixhub or our package indexer. Needless to say, we have much to do to improve the installation experience.

Infra & Ops: Docs are bustling, which means no more room for downtime. I began shifting docs to Vercel last week, wrapping up now with the old CICD deploy task retired. Meanwhile, our Devbox Cloud Docker image failed to build due to a breaking change from Caddy. The issue was unblocked by locking Caddy at 2.6.4 and the JWT plugin at 0.9.0. Simultaneously, our Nix Packages cache on Fly.io nomad machines are causing instability. Past migration failed due to large DB volumes. This time, I scaled the app down and manually migrated to their V2 platform (instead of using the fly migrate-to-v2 command). They are running ok now.

Mike

This week worked on a mix of bugs, performance, new features, and some future planning. Fixed a long tail bug where plugin flakes are not added to nix profile. This work is needed in advance of removing bin wrappers. Speaking of bin wrappers,  we removed bin wrappers from path when using devbox run. This should give a pretty nice perf boost especially for folks that use coreutils. We’re hopeful we can remove bin wrappers from all devbox commands soon.

I also merged (and released!) the commonly requested --env and --env-file flags which allow people to add/override environment variables as needed. One cool use case for these is to use together with direnv allows you to keep a gitignored .env file with any individual vars you have. These are available when you cd into your project, but don’t pollute your environment anywhere else.

Mohsen

It’s been a busy week. My main focus was helping Lucille updating our devbox.sh so that we can later on accept user submitted templates. This involved changing the API calls the frontend makes to devbox cloud gateway, as well as changing the bash script that we run when a devbox cloud image starts. With this new update we take a Github repo instead of just a template name. This also affected our Devbox CLI command so we had to make changes to devbox create command so that it accepts git repo parameters as well.

In the midst of testing this I accidentally caused an HTTP 500 alarm to be sent to our monitoring system, but it was a false alarm which was caused by testing Open In Desktop feature. But on the bright side we confirmed that Open In Desktop works after it was broken due to a VSCode update that changed the way it handled opening URLs.

On the side, I added a flag to our devbox generate dockerfile and devbox generate devcontainer so that the generated Dockerfiles use root user or a devbox created user. This was due to a few user reports that forcing either breaks their use cases so hopefully this way the choice can be made to fit any use case. Besides that, we published our VSCode extension to Open VSX extension marketplace last week so I did some testing to see if all the features work the same. I’m planning to add a docs page on that next week.

Rodrigo

This week I mainly focused on implementing metering, so that we can measure how much time, cpu, and memory a given user has consumed while using Devbox Cloud (devbox.sh). The metering should allow us to aggregate usage across different VMs and/or projects. Once we can accurately measure usage, we’ll be able to re-enable a free tier for Devbox Cloud with some limited quotas.

I also spent some time fixing a bug related to nix profile installations, in the context of a larger feature: removing nixpkgs. More on this feature when we’re able to ship it (hopefully soon!)

Savil

This week I mainly worked on enable per-OS packages. This has been a longstanding user request. Some projects require glibcLocales as a dependency, but only when running on Linux. Furthermore, doing devbox shell with a glibcLocales in one's devbox.json would fail to run on Macs. Similarly, other scenarios have required darwin.apple_sdk.frameworks.Security to be installed on Macs. And again, such projects would fail to run on Linux. So, we needed to enable a way for packages to be excluded from certain platforms, or run only on certain platforms.

One stumbling block with doing this is that our packages are a simple list of strings:

{ 
  "packages": [
    "go@1.20",
    "glibcLocales@latest"
  ],
  ... 
}

So, the first task was to enable each package to optionally be a map. We can then add properties to it:

{
  "packages": {
    "go":"1.20",
    "glibcLocales": {
      "version": "latest",
      "platforms": [ "x86_64-darwin", "aarch64-darwin" ]
    }
  ],
  ...
}

Implementing this in a neat manner took some iteration. The golang code has to optionally parse packages as []string or map[string]Package. And because the order of []string has semantic meaning, we needed to use an ordered-map for the json parsing. This is non-standard, since JSON specifies maps to be unordered. Anyhoo, I'm quite happy with how the code turned out.

Once this was in place, I thought I'd be done by mid-week, since I just have to implement some flag handling devbox add --platform <platform>. How hard can it be? Turns out, I overlooked the fact that we now a new concept of "installable" packages which is distinct from all the packages. So, I needed to audit a lot of callsites and ensure they're appropriately invoking InstallablePackages() or ConfigPackages().

After all that, and some valuable feedback I got from code reviews and from the team during our Demo Day, I finally got it in before the weekend. It'll be in the next release!

Greg

Made a bunch of improvements to the pipeline that builds the package search index behind Devbox and Nixhub. Before, we were evaluating a giant Nix expression to get package information (versions, descriptions, etc.). All of that has been replaced with Nix CLI commands that run a lot faster and use 1/4 the memory. The new pipeline is also more resilient to errors that sometimes pop up when walking the tree of packages.

All of this will let us automate updates to the index so that new packages in nixpkgs are available in Devbox faster.