Calling all fans of Brew!



We recently hosted a webinar with Workbrew Co-Founder and CEO John Britton, who demonstrated how to standardize software delivery and patching across your Mac fleet while preserving developer experience.



Learn about insights and practical knowledge to improve visibility into your software supply chain, standardize and manage software delivery for developers as well as for your entire fleet, and tools to ensure that your systems stay secure and compliant.



Workbrew is built on top of the popular open-source package manager, Homebrew, and extends its functionality to support the multi-player workflows small teams and large enterprises need.



Your company will love Workbrew because your fleet of all machines using Homebrew will have faster onboarding, quickly mitigated security vulnerabilities and consistency in Homebrew usage across your teams and projects.

About the presenter

John Britton is a developer, entrepreneur, and investor. As Co-Founder & CEO of Workbrew he’s on a mission to improve the way software is deployed and managed at organizations. He is an industry-leading expert in the realms of open source and developer-tools go-to market, with 20 years’ experience in system administration, networking, and software development.

Watch the Workbrew webinar recording

Miss the webinar or just want a refresher? Watch the recorded webinar on demand.

Read the Workbrew webinar transcript

Dive into the details and read the Workbrew webinar transcript:

Introduction

Lauren Cabana:

Good morning or good afternoon, everyone, depending on where you're joining from.

Welcome to our webinar today with Workbrew: Secure Software Delivery at Work. We're going to give joiners about one to two minutes to get on the call and then we will get started.



For those who are just joining, thanks for hopping onto our webinar this morning or afternoon, evening, or depending on where you're calling in from.

We'll get started in one moment, but a few technical things off the top before we jump into the content. John has graciously agreed to accept questions today. So, if you have any questions as you go, as we go through the webinar content today, feel free to drop them into that Q&A box. We'll be able to see them. We'll do our best to answer them in line in real time, and we'll have some time reserved at the end to take additional questions.



All right, John, we're about 3 minutes past the hour. I think we can probably safe to go ahead and get started. We are recording the webinar in case anybody jumps in late or needs to share with a colleague later.

John Britton:

Perfect. Yeah, I'm happy to get started. Thanks Lauren, and thanks to MacStadium for hosting. I'm really happy to be here. Let's get started.



Hi everybody, my name is John Britton. I'm the Co-Founder and CEO of Workbrew and today we're going to be talking about secure software delivery at work.



So for our agenda, we're going to talk about Homebrew, Workbrew, how to deploy Workbrew and then I'll give you a demo of the product followed by Q&A and a session at the end. So as Lauren mentioned, please put your questions into the Q&A function in Zoom. If I see them as we're going and I'm able to address them, I'll address them in real-time, but I'll answer the remaining ones at the end. And if there's something I can't answer today, I will follow up with people with answers to those questions after the fact.



So a little bit about me and the team, my background. I'm a software engineer by training. I've spent most of my career working on developer tools. I'm also a Homebrew contributor. So Homebrew, I started doing that maybe 10 years ago or more, but I have two excellent Co-founders, Mike and Vanessa. Vanessa is on the Homebrew project leadership committee and Mike is the Homebrew project leader. He's also our CTO.



So together we have some of the most experience in Homebrew in the world and we're very well positioned to help you solve these kinds of problems for your organizations.

What is Homebrew?

So let's get started with Homebrew. What exactly is Homebrew?



Lots of people ask me this question all the time, and in the most high-level kind of way of explaining it. It's the best App Store for developers.



If you use a Mac, it'd be hard-pressed to, you know, do software engineering without having access to Homebrew. It originally started as something that was primarily for open-source software developer dependencies, but it grew into a lot more than that.



Homebrew is an open-source project with thousands of contributors and over its 15 years of history it's become the de facto package manager on macOS.

Challenges with Homebrew for enterprises

So Homebrew sounds great, right? But there are a few problems.



Homebrew was built with a single-player use case in mind, which is not a problem for the average developer. But when it comes to using homebrew in a team setting, the more and more devices and the more and more members of your team that get involved, you know, you get different kinds of challenges that you need to, you know, solve that Homebrew is not really well equipped for. Things around like standardization, automation, visability, all kinds of multiplayer cases that are not covered.



Additionally, has no visibility at all outside of the individual user. And there's no, no guardrails. There's nothing that prevents the user from doing things that they're not supposed to, whether that's for compliance or regular regulatory users.



So, what can you do, right?, If you're using Homebrew in your company, how do people solve these problems? We see three very common patterns of how companies address managing Homebrew in a corporate setting.



The 1st and most common is to just do nothing. You know, officially we don't talk about it. Homebrew is not allowed, but everybody knows that all the developers are using it and we kind of just look the other way. This is definitely the worst option, but it's also the most frequent.

The next kind of middle ground that we see is what we call informed trust. The idea here is that the organization understands the risks and the benefits associated with Homebrew. And maybe they have some policies that are understood or even written down around how Homebrew should be used, around how you should vet packages and keep things up to date, and minimize your dependencies. But ultimately, there's no enforcement of any of these rules. So it's kind of like a trust but verify situation. Please don't install things that are out of scope of what your job requires you to do. And we kind of just trust everyone to follow the rules.



And then the last, which is the least common, but it's actually very popular in the largest companies, which is to roll your own solution. Homebrew being open-source, you can pretty easily integrate with it writing your own scripts, whether it's with your MDM software or with some kind of deployment tools like configuration management. And many of the largest companies in in the world that use Homebrew, and I've spoken to folks at these companies, they have entire teams dedicated to essentially running an internal mirror of Homebrew for all of their 10s of thousands of Macs in their developer population so that they can stay compliant and meet their regulatory requirements without limiting developer productivity. This is generally out of scope for most companies.



And so this is also where a Workbrew can help out.

What is Workbrew?

So let's talk about Workbrew a bit. What is a Workbrew?



Well, I like to think of Workbrew as enterprise-ready Homebrew. It's everything that you love about Homebrew, the developer experience, everybody's come to love, but also in a way that fits your organization's requirements. So it's approved by security. It's a paved road, as we like to say in engineering, like what's the path for using this kind of tooling? And it essentially gives you a standardized way to deploy, manage and secure Homebrew throughout your entire organization.



Broadly speaking, the functionality of Workbrew falls into a few categories. 1st is developer productivity. So Homebrew is already famous. It's installed on 10s of millions of devices. There are a lot of benefits to using Homebrew. You have access to a wide variety of packages, easy to update them, ways to share them, all kinds of different functionality. And so with Workbrew, what we do is we try to make that something that you can standardize across all of your developer teams and your developer environments and make it really easy for them to get up and running.



Next is analytics observability. This is the number one thing that I hear from IT and security professionals in companies where they're using Homebrew. They say, you know, we don't even know how many endpoints have Homebrew installed, let alone do we know what packages or which versions or what vulnerabilities we have within those packages on those devices. And so Workbrew aims to give you visibility, so you know what's going on within your organization and within your fleet.



Next is remote management. As I mentioned before, Homebrew is built for a single-player experience. Imagine the case where you have a development team and you have a new dependency or you have some new prerequisite for your developer environment. I've seen over and over that when this happens, what teams do is they'll just communicate with all of their developers. “Hey, please run this script” or “Run these 5 commands” including brew install and brew upgrade and all these different things.



Rather than trying to do all this ad hoc, with Workbrew, we give you a centralized way to manage this across all the devices in your fleet, across individual groups of devices, or targeting individual devices specifically. You can essentially do anything that you can do with brew across your target devices, whether it's individual or group of devices or all the devices in your fleet.



And then certainly, last but not least is security and compliance. So within the scope of using Brew, it's important to be able to set parameters of how people can use this. You know, we'll often get questions from companies in highly regulated industries like the financial sector or healthcare or insurance or government, and they'll say, hey, look, you know, Brew is great and our developers love it. But there's this one type of software that we just absolutely can't have on our devices. You know, a frequent one that I hear is network tunneling software. And so they say, hey, how can we put some policies in place to limit or at least alert on the case when network tunneling software is installed?



So with Workbrew, we give you the ability to do that and, and gain visibility and, and set guard rails around, you know, your security and appliance requirements. What you see on screen here is also vulnerabilities. We keep a database of all known vulnerabilities across all packages in the Homebrew ecosystem, and we will alert you in real time and give you one-click remediation for those vulnerabilities as well across your entire fleet.

Workbrew architecture

So I want to take a moment to talk a little bit about the architecture of Workbrew and how we came to the solution.



First and foremost, the foundation of Workbrew is Homebrew. It's open-source Homebrew through and through. We don't have our own kind of custom version or a fork of Homebrew. We use the exact same Homebrew that everybody else uses, and we're contributors to Homebrew.



As I mentioned, I'm a contributor to Homebrew. Vanessa is on the project leadership committee, Mike is the project leader, and we have several engineers on our team who are also maintainers of open-source Homebrew. So whenever we find something that is beneficial to our customers, but it's also relevant to the entire Homebrew audience, you know, we'll upstream it and make it available to everybody through Homebrew. So we start with the foundation of open-source Homebrew and then on top of it.



That's where Workbrew comes in, and it has three components, an installer, an agent, and a console. And I'll walk you through each of these a little bit when I go through the demo.



But essentially what we're doing is we're giving you an orchestration layer or a command and control layer for Homebrew across many devices.

Workbrew deployment

Let's talk about deployment.



So when an organization decides that they need to kind of get their hands around Homebrew, there are a few different stakeholders involved. Typically it's the IT team, maybe it's a head of IT or an IT manager, somebody from the security team, whether it's like CSO so or a security manager or somebody from the risk department. A lot of these regulated companies have risk functions that are specific to this kind of thing. And then generally there's also the engineers, right? And each of them has their own kind of motivations here.



Something that we've taken into consideration as kind of a guiding principle in building Workbrew is that this isn't a give-and-take relationship between all three of these different audiences. What we want is a solution that helps all of them without hurting the others.



So in the case of engineering, I talked to companies and there are engineers that say, hey, we're not allowed to use Homebrew at work. Why? Because it's not secure, it's not compliant. We can't manage it. So we're just prohibited from using it at all. And for those folks who want to bring Homebrew and, and give them access to it. So with Workbrew, you know, engineers get access to the tools that they love, the tools that they're used to. Security gets peace of mind. They don't need to worry. When I talk to security professionals, you know, day in and day out, the thing that they say over and over again is this makes me really worried because I don't know what's going on.



And then for the IT team, it's really about, you know, they end up being the ones who have to do all the work. So I've seen companies where they don't have access to Brew, but they still need access to all of those open-source tools. And those IT teams are tasked with using their MDM tool to create individual packages for every single piece of software that they depend on from Homebrew and keeping them up to date. And that's more than a full-time job for someone to do. So for the IT team, this makes everything that would take them hours and hours, days and days into just minutes, kind of a set-it-and-forget-it story.



Additionally, when you deploy Workbrew, there are three different kind of modes for permission that different companies might choose to use. And this is all kind of a decision that you make as part of your deployment.



Broadly, they're restricted, managed, and guided. In restricted mode, this is when a user on a Mac machine is a standard user without admin privileges and you install Workbrew. Essentially, it's a headless version of Brew.



So they get Workbrew installed on their device, they get all their default packages. The IT and security team get remote management capabilities so they can install packages, upgrade things, check for vulnerabilities, patch, etcetera. But the end-user has no direct access to Brew. Among our customers, this is used for folks who are not savvy with the command line but could still benefit from the 14,000 packages in the Homebrew library as a standard way of deploying software across the organization with really, really easy patching.



Manage mode is more tailored for a software engineer who is familiar with using the command line. The way that this is configured is by adding the user to a system group called Workbrew Users, and which gives them access to the brew command line.



Now, from Workbrew's perspective, when you install Workbrew, you get access to the same brew command line as you would normally have. That looks and feels and behaves exactly the same. You don't need to learn anything new. There's no login, but we have kind of a layer there where we're parsing all of the commands and making sure that they're within your organization's policies and requirements.



And then lastly, guided mode. We see a lot of organizations, especially in startups and fast-moving technology companies where the end users have admin privileges on their device or they have a privilege escalation tool like SAP Privileges or Beyond Trust or something like that, where they can go from a standard user to an elevated privileges admin user on demand. And with those folks, they get the same experience, but they're not subject to the same kind of enforcement parameters. So you get to choose as an organization and you don't have to make the same choice for every user. Some users might be restricted, some might be managed, some might be guided. And so all of this is to kind of get you in the mindset of like what it looks like to deploy this out to your fleet, who's involved, what are the decisions?



And really you can deploy work through in a matter of minutes. We work with every MDM tool. They all support PKG installers. All you need to do is take the Workbrew installer, put it into your MDM, install Xcode command line tools, and then choose which mode you want your user to be in. And that's it. You can be up and running from 10 to 10,000 devices, in a single day, in a couple of hours.



What I'm really excited about is that Workbrew is entirely free to deploy for unlimited devices and unlimited users. And when you do that, you get access to Brew on the devices, access to the Workbrew console, and full visibility into everything that's going on in your fleet.



So, following today, if you like what you see here, I would definitely recommend that you go and, you know, try this out, install it on your devices, and get that visibility.

Workbrew demo

So now I'm going to jump over to my web browser and show you a demo of the Workbrew product.

So now that we have the context of kind of the architecture and the goals and why we don't work through, I want to give you kind of an overview of the functionality.



And the functionality of the product falls into three main categories, visibility, remote management, and security compliance. And as I mentioned in the deployment section, that visibility is completely free.



So I'm going to start with that and show you what you can get just by installing work through onto your devices and setting it up with the console for unlimited devices, unlimited users and basically shine a light on the darkness within your organization. Know how many devices have Brew installed, know what's installed there, know what versions are there.



So the first thing you see when you log in is you know this screen and then on the left-hand side you can go to your dashboard.

The dashboard gives you a high level overview of everything that's going on in your fleet. It will report vulnerabilities to you, outdated packages, any devices that are not up to date with Workbrew and any failures in your commands that have been running. You can also drill down into each of these sections and get information about what's going on right on this page. This is really just a high-level view.



Up next, I'll take you to the Devices section.

From this page you can see a list of every single device in your fleet along with its MDM information. So if you use one of the major MDMs, we have a device inventory syncing functionality that will pull all your device names in. So you don't have to manage this manually. And from here you can see kind of a summary, you know, how many packages are installed, when was it updated, things like that.



And then you can within a single device, you can go here and for example, drill down on device and you can get full information on every single package that's installed on that device, whether or not it's up to date, what version it's on, what license it is.



And all of this disability is included for free. In our paid plans, you also have the ability to do one-click upgrades. So this is something that's like an active action. Anything involved with doing a right action is part of the paid plan. But the read side is included for free. You can see all these packages, see what's installed. This is really useful for something like troubleshooting. You have a particular person who has a problem with their device. You can drill down on their device and get information. It's useful for instant response.



Say something goes wrong and you're trying to get an audit log or get some information about what happened on a particular device. More often than not though, what you'll want to do is look at this from a high-level view of all of the devices.



So there's this packages view, which is the same information that I just showed you, but instead organized on a per-package basis. So you can see every package that's in your fleet as well as the devices that it's installed on, whether it's up to date everywhere, was it installed by request or was it just installed as a dependency of some other project. And you can see licensing information and things like that.



This is really useful for finding out what are the most popular packages, upgrading things that you know you want to go and see, like what is this impact?



And also understanding where things are in use. One of the most common use cases our customers have, is to say we want to know what's in our environment and we want to limit that just from a good hygiene perspective. We want to have as few dependencies as possible. And what they'll do is they'll come into this list and have a full audit of everything that's installed, and they'll find all the packages that are installed on just one machine. And then they can make some decisions about, hey, should we be requesting this to be removed?



Is it important versus the things that are installed on dozens or hundreds of machines that are a very important dependency to the organization. You know, they can then manage that themselves.



Additionally, I'll talk about taps.

So homebrew has a functionality called taps. A tap is a repository of packages. There's an official tap for Homebrew called Homebrew Core, and there's another one called Homebrew Cask. Those two taps together have about 14-15 thousand packages, and that's what most people think of as Homebrew. You can see those here.



Now, as I mentioned, Homebrew is kind of like a piece of infrastructure that does the work of getting packages and installing them onto your machine. But you can use it with any packages, not just with the official ones. And so there are third-party taps available where you can go out and find other repositories of software. And with Workbrew, you can gain visibility into what third-party repositories of software, what third party taps are used in your organization. And with this, you can see, how many people are using them, what packages are being used, and just have a better visibility into how this is happening in your organization.



Similarly, with licenses, a lot of our customers want to know what goes into their into their products. They might have licensing requirements around things like GPL where they'll say, you know, we want to limit our exposure and want to have minimal GPL software. You can come in here and you can find out all the licenses, how many packages use those licenses, where they're installed, and things like that.



Then analytics essentially gives you full visibility into what has been done with Brew on the devices throughout your organization. So you can see when packages are installed, when they're upgraded, when they're started and stopped, if they're brew services, you can see if people are pinning or unpinning packages. And this is useful for folks who need to have a high level of auditability around what's going on in their organization.



So everything that I've shown you so far is part of our free plan. So if you go, when you install Workbrew, it'll be, you know, the same developer experience and you'll have all this visibility. I would highly encourage you to give that a try.



Beyond visibility, the next big area is remote management.



And so to show you remote management, I'm going to start with our device grouping and then also talk a little bit about how brew commands work.

So if we go back to the devices screen from this list, you can go down the list and you can choose some devices and you can add them to a group or you can create a new group. This is just so that you can organize them for targeting.



As you can see, you know some of these devices already have groups assigned to them, and that comes in handy when you're trying to manage the fleet. You might not want to run, you know, each command on each device manually. You might say - all of the engineers should have these things done. All of the data scientists should have these, all the customer support people should have this, and so on and so forth.



So that's device groups.

Once you have device groups, we have a functionality called default packages. You can create a list of packages called a default packages list, set those up, and then assign them to a target.



So for example, let's say new default packages. And in this field you'll just say “Python” and “Postgres” and you could say “curl” and “git”. And this format that I'm using is a format called a brew file. So this is part of Homebrew, the open-source project.



There's a functionality called brew bundle, which takes a brew file and installs all of the package list packages listed in that brew file onto your machine. With Workbrew, you can create a brew file in the default packages in a setting, configure that, and then assign it to a group or a user or whatever you like. So in this case, I could choose to assign it to all current devices, and now every device that's in my fleet will get these packages installed. I could also choose all current and new devices.



So what this would do is every time a new employee joins the company, or somebody gets a laptop upgrade, when they start it up, they'll get all of this stuff installed by default. So you can really streamline the developer onboarding experience with this. And you could, of course, do this on an individual device basis.



So that's one of the first kind of most useful remote management functionalities. But on an even broader level, we have this brew commands interface.



Essentially any command you could run on the command line, brew install, brew upgrade, brew pin, brew tap, you can run, you know, through this interface and you can even schedule them to run on a recurring basis.

Let’s say, for example, do a new brew command. And I'll say I want to make sure that Python is always upgraded. So I can set Python, I can choose a target for example only my engineers and I can set a schedule to run daily. So now every day Python will be upgraded. I don't know if I would recommend this as an actual use case. It might be a little disruptive for Python to be changing out from under your engineers without them being involved. But there are other cases where let's say for example, you know git, you always want git to be on the latest version. There's no reason not to. So you could do that as well.



With the brew command, what happens is once you create the command, it fans out into a number of runs. So in this case, we have a command brew upgrade gh, and you can see it ran on a number of devices and you can see it was successful on those devices.

And this history is also you can drill down and get the full log output. So if I go and I take this one, you can see exactly what happened on my device. This is equivalent to if I had sat at the terminal at my device and run brew upgrade gh, this is what I would have seen. And you get that for every device in your fleet. So that's the remote management side of things.



Lastly, what I want to talk about is security and compliance.



So on the security front, there is a big differentiation in the way that Workbrew is on your system versus the way that Homebrew is on your system.



So when we install Workbrew, we essentially isolate the user from the package manager. They don't have direct access to Brew, they have access to Workbrew, and we pass through only those things that are permitted by your security policies or compliance policies and so on and so forth.



An added benefit in this case is that your end users can have the full Brew experience without having admin privileges on the device.



So there are many companies, many organizations that I talked to where they say - our engineers, our end users don't have admin privileges on their device. And because of that, Brew is really problematic. They have to jump through a lot of hoops to make it work. With Workbrew, it's just it's supported out-of-the-box, so you don't need to be an admin. And that comes from this isolation principle of least access kind of style of setting things up.



Additionally, I think I mentioned a little bit before about vulnerability scanning, so I'll show you the vulnerabilities dashboard here.

What we do with vulnerabilities is we maintain a number of separate a number of data feeds where we pull information on known vulnerabilities and we cross reference that with all of the installed packages and versions across your entire Homebrew fleet. And when we find a match, a vulnerable package in your fleet, we'll send you a notification. We can send an in product notification, we can send you an e-mail notification, we can send you a Slack notification to a child that you specify, and we can also send you a webhook.



Then once you are alerted, you can come to this dashboard and you can see all of the vulnerabilities along with their CVE identifier. And you can drill down and get more information about what that CVE is and see if it actually is a concern for you. And when available, we also provide this orange and red pills you see here, there's a CVEs score. So when we have that, we'll also give you that. And you can see what's impacted.



So for example, this CVE for libuv impacts 4 devices. And I was to click this, it would take me to the device screen showing me the four devices that are impacted. And with all of these, typically what happens is when CVE is published, the upstream vendor will patch the vulnerability and they'll make that new version available.



Since Homebrew has thousands of contributors, generally those patches, those new versions are available in Homebrew very quickly, you know, sometimes on the order of minutes or hours, definitely within a day. And if that patch is available, you'll see this button here, one-click upgrades. So I can just click this button and immediately patch all those CVEs.



And so this is like, if you think back to last year, there was the XZ supply chain attack. A sophisticated attacker infiltrated an open-source project. It was a downstream dependency from lots and lots of different projects. They crafted a very malicious attack that was obfuscated, got it into that project, and then luckily someone discovered it. And when it was discovered, everybody was asking, “Hey, how do I know if this is installed on my devices or not? And how do I patch it?” Well, you can see right here, we know the CVE is here. You can see that the, the vulnerability exists one-click and it's patched.



Now when that supply chain attack was discovered, you come into work through one click, and all your machines are patched in minutes and you have visibility into whether or not they were successful. You can track down which devices need to be perhaps connected to the network to complete the update or anything like that. So that's, that's vulnerabilities.



The last thing that I want to talk about on the security and compliance side is actually policies and enforcement.

So what I'll show you is this Brew configurations feature that we have Homebrew, you know, is a open source project. It has lots of configuration options. And those configuration options, there's close to 100 of them. And they let you do a lot of things.



They let you do things like limit what taps are available to Brew. It lets you set things like, you know, local caching. It lets you set things like packages that you want to disallow. This is all built into Homebrew.



The thing that you're missing from the single-player to multiplayer kind of set up is a control plane where you can set those settings across your entire fleet and enforce them. And so what you get with the brew configurations is essentially that. So I'll use the example here to create a new brew configuration.



And I mentioned when I was talking about taps that anybody can create a tap and put any arbitrary applications and code into it. And so that could be a vector of tack for you.

So what you might do in your organization is do something like this - Homebrew allowed taps and set that to be Homebrew core and Homebrew cask. And by setting this, what you'll do is essentially limit those devices that you target.



So in this case, I'm targeting all devices to only be able to install packages from the official Homebrew taps. So those 14,000 packages that are human reviewed by the Homebrew open-source project. You can do other things here. We talked to a lot of organizations that are required to keep audit histories. Things like code signatures, approval dates and time stamps, and all kinds of metadata around when things entered their environment. You could use something like Homebrew artifact domain to essentially run a mirror of all of the assets served by Brew inside of your network.



And then from that host, that's your mirror, you could run auditing and scanning software on that host, so that you had fingerprints and timestamps and audit history that's required due to your ISO compliance or whatever it might be. And what's great about this is it has no negative impact on the developers. They get their exact same experience, but you get to check the box that says, yes, I'm doing the steps that I'm required to do under my compliance requirements.



For example, one last thing that I'll show here is Homebrew forbidden formula. So for example, you know, we always get this question - how could I block some certain packages because we don't want them in our environment. For example, you might want to block BitTorrent. So to do that you would just say BitTorrent set this and this would be enforced on the device according to those three different permission models we talked about. In restricted mode, the end-user has no access to brew whatsoever, so it's not relevant. They couldn't install it anyways.



In managed mode, what would happen is if the user said brew installed BitTorrent, they'd get a message and it would say “This package is disallowed in your environment, please contact” and then whatever you specify, the IT department help desk on this Slack channel or at this URL, submit a ticket to request an exception or to request to just be added to our environment.



So that gives you kind of a high-level look into visibility with Workbrew, room management, and security and compliance. Beyond that, I think that the last thing that I wanted to say is just that all of the visibility functionality is available for free. It's absolutely worth your time to go and have that.

Q&A section

So the first question is, “Is it possible to pin a package to a specific version?”



So this is a question that we get a lot and it's kind of nuanced. Often times people ask us can we use the same version forever? And the way Homebrew is set up is it's a what's called a rolling release package manager. Essentially, every time a new version of software comes out, the latest version is shipped. And this is in contrast to other package managers.



Let's use APT from Ubuntu, for example. The way that APT works is when Ubuntu makes an operating system release, they freeze all of the packages and those packages stay available as the version for that version of the operating system. So Homebrew is distinct from that in that it's always on the latest version.



And this is really valuable for developers because they don't really want to wait for their operating system to be upgraded or a new release to happen to get access to the latest dependencies. But with that comes a little bit of a challenge, which is that Homebrew doesn't ship old versions. So once a new version is available, you can't install an older version from Homebrew. Homebrew does support a functionality called pinning, which is essentially a way to prevent a package from being upgraded.



So with Workbrew, what you would do is you'd go into the console, you'd go to brew commands, you would say brew pin post press or brew pin Python. And now if the end user tries to upgrade it, or if another one of your scripts or another one of your management functionalities try to upgrade it, it will not be upgraded. So that's definitely possible.



And then another person asked “How can I bring my own package to Workbrew?”



I assume that this this is related to the idea of using Workbrew as a way to distribute internal software or your own software. Not “I'm a software vendor and I want to put my package into Homebrew so other people can download it, but I want to do it internally.”



The way to do that is to create a tap. And there's a really great guide on the Homebrew website. So if you go to brew.sh, there's a documentation section and in there there's detailed documentation on how to create a tap. And a tap is just some text files. Generally, it's on a git repository, usually GitHub. And within that repository, you have a couple of files that describe what the packages are. And then from the brew command line, you use the command brew tap. And with brew tap, it will connect to the tap and get the information. Then within that tap, it essentially has instructions on how to install those packages.



The instructions are called formula, and the formula is written in a domain-specific language that looks like plain English. So it's actually very easy to write and to manage as compared to some other packaging tools that are like very sophisticated, complicated XML files and things like that. Writing a package for Brew is actually quite easy.



There's a question that says “What about the scenario where a specific software version is needed for some reason?”



So as an example, we might say there's a package X and the current version is 2.0 and you want version 1.5. Today with Brew, there's no way to get version 1.5. You can only get version 2.0.



However, we have some ideas around additional functionality that we could be adding that will make that easier for you to solve that problem. But there's nothing today that does that.



There are two questions about pricing. One is, “Is there a trial?” And then “Can we give an idea of pricing?”



So yes, there's pricing on our website, it’s workbrew.com/pricing. The pricing is $10 per month per device. And we have an enterprise plan that is specific to highly regulated organizations. So if you have specific compliance needs like you have a very large fleet and you need to be ISO certified and things like that, then we would talk to you about setting up a trial.



Our trial process is for the enterprise product, for our pro product, which is the $10 per device per month. You can go and up on the website today for free and upgrade if you want to use the remote management tools.



And then we have another question here that says “As Brew does not allow installing an older version, it's not possible to recreate a development environment that uses an older version.”



So this is this is a challenge that comes up all the time. Generally, when it comes to a development environment, there's different types of dependencies. So one type of dependency might be your language dependencies.



Let's say I'm a Python developer and I have Python libraries that I'm depending on. And typically with Homebrew, the dependencies that you're installing are system-level dependencies, not dependencies for the code, but they might be, for example, a database or a caching layer or some kind of a queuing system that's installed system-wide. And so it's a challenge to install multiple different versions of those things on the same system. But we have some things in the works that will help out with that in the future. But right now to this question, it's not possible to install a version that's not currently shipped by Homebrew.



These are all great questions. Thank you so much.



This is a little bit specific, but it basically says “Is there an option for an externally configured install of the work through PKG? Is it unique per tenant as I work with multiple independent organizations.”



So this sounds like this person might be like a managed service provider where they're doing outsourced IT work and they want to manage multiple different clients who have multiple different MDMs. Actually the answer to your question is yes, the Workbrew installer is standard. It's not unique to a tenant.



The way that we actually do this with the MDM is that you load it the PKG into MDM and it's a three-step process. The first process is prerequisites, so you make sure that you install your Xcode command line tools and we provide a script that will do that for you through your MDM. Then you write an adjoining key to disk so that you can connect your device to the workspace. Then you install the PKG and then following the installation of the PKG, optionally, you can add the user to the work per users group to give them access to Brew. And so all of that is done with one standard PKG installer. That's not unique on a per-tenant basis or per-user basis. It's the same one.



And there's another question that says, “Are there any risks? Is there a chance that it can break users environments?”



We designed the Workbrew installer to be nondisruptive for existing Brew users. So when you install Workbrew, you can have a brand new machine out-of-the-box that gets Workbrew installed and you're up and running zero touch. Or you could have an existing user who has Brew installed on their device and you could run the installer on their device and it would be transparent to them.



What happens is because we're based on open-source Homebrew as the foundation, all of their existing packages stay installed. Their existing Homebrew installation still works. We upgrade them to the required latest version of Homebrew, and then we put the Workbrew layer on top of it on their machine and we update their permissions in such a way that we have this isolation that I was talking about before.



So with all of that, it's essentially transparent to the user. To be completely honest with you, there has been one place where sometimes people have a little bit of friction and it's very easy to fix.



But for developers who have very customized terminals, what ends up happening for them is sometimes they're writing to their path, they're configuring their path multiple times and their, and their dot files and their configuration settings and their Z pro, their, their profile and all that kind of stuff.



We require that Workbrew be in the path. And if for some reason they're overriding the path, they can get a a message that's like, “I don't know what's going on”, but it's almost always just that they have some kind of customization on their terminal that's overriding the path. And it's a very easy fix. And those type of users that are doing that generally know exactly how to fix it. So it hasn't been much of a problem.



All right. Well, I think we should call it with that. Thank you all for coming. This was really fun. And Lauren and MacStadium crew, thank you for having me. I've had a great time.



Lauren Cabana:

Yeah, thanks, John. It's been great. All right, everyone, have a great afternoon. We'll see you next time.

Discover more mobile app dev solutions

Platforms like MacStadium keep you updated with all the latest mobile app development solutions. See how Orka Cluster can help you get truly automated CI on macOS VMs. Use Citrix? Check out how you can add Mac to your Citrix DaaS.