Hello. I'm Paul McKeever. I'm VP of growth here at Cloudsmith, and I'm delighted to welcome you to today's webinar. It's an introduction to Cloudsmith. We're gonna be talking about some of the challenges and considerations you might have around artifact management, what it means for teams who are consuming open source software, how to enable developer productivity with code reuse and how to have fast reliable deployments in your development process.

I'm delighted to be joined and welcoming today my colleague 1 of our technical account managers. Dan, why don't you introduce yourself?

Yes. Hi, everyone. So I'm Dan McKinney.

I'm a technical account manager at Cloudsmith. I will do a short demo today, a bit of a platform overview. Myself and Paul could talk about artifact management for for hours and hours and hours. So we will do our best to cover as much as we can in the short time we have. But, yes, thanks for joining.

Given the opportunity, we will. We promise we'll keep this short today. So today's session is a brief overview. And like Dan said, there are so many different aspects that we could talk about. I'm gonna begin just by describing how we see the market and some of the challenges[00:01:00] that your teams may be thinking about.

So I have a couple of slides here, and then I'm gonna hand over to Dan, who's gonna show you how you can address some of this in your workflows. So why do we think artifact management and software supply chain security is important? Well for every business today I can't think of a single sector where software isn't important to your commercial success. Your ability to deliver great customer experiences, to move goods and services around the world, all rely on software on depending on those businesses. And so if software defines how competitive your business is, then you should be excellent at software.

And having your investments in development turn into tangible results is really important. So producing software efficiently means things like reusing software. So when we say most software isn't your software, what we mean is that for your development teams to be productive, you're going to [00:02:00] be building on the open source libraries that exist. Why write something from scratch when someone's done it before? And we're blessed with a wonderful resource of open source libraries, everything from application servers, operating system packages, cryptography, right down to small little JavaScript libraries that trim the spaces off text.

And it's thanks to all of the creativity and invention in the open source community that we're able to focus our efforts and our talents on building software that's unique and valuable to our businesses, the things that make us distinct. But because we're consuming these resources, we have to be conscious of some of the things that they bring with them. So when we use an open source library, we commit to comply with the license that it represents. Most open source licenses are are very flexible, but they're not all the same. And so that's an important consideration for compliance.

It's also important to think about what types [00:03:00] of assets you're bringing in from the outside world and shipping to production. So that's why we say you need to control your software supply chain from end to end. When you're consuming these dependencies, incorporating them into the products and services that drive your business, and deploying them into environments where your information and assets are are going to be used, it gosh. It's critically important that that software is secure. And so you should take care over what software you consume, where it comes from, and how it's managed.

So that's the premise behind Cloudsmith. The founders of the company previously worked in a software environment where applications were installed on servers and data centers. And they left that experience thinking, well, we're living in a world of distributed teams, and the companies and the global businesses today have, you know, employees all around the world. They also have customers all around the world [00:04:00] who are often consuming software too. So we talk about the importance of being cloud native, that you should have a solution that covers every artifact and every team across your organization, but built on the cloud instead of in 1 of those data center servers or applications.

So Cloudsmith is a way to store all the software artifacts, the open source packages, the software that's packaged for execution, like Maven packages, container images. And then we have a dependency firewall. That means that instead of having developers going to the public Internet and pulling those things directly from Maven Central, PyPI, or NPM JS. You can implement a control plane. You can proxy and cache those artifacts, and you can decide which ones you're comfortable with, which meet your expectations and your policies for things like license compliance and and vulnerabilities, make sure there's no malware in there, and then have controls over what gets shipped to production.

You can do that in a way where instead of relying on network access in your on premise environment [00:05:00] historically, you can have a 0 trust security model using things like your identity provider as a as a source of truth, using things like OpenID Connect to prevent data exploitation and to have, you know, the right controls over what pipelines can push packages that are deployed. And lastly, because your development organization and and your investments in software development exist to be productive, you wanna build great software. Well, we believe in enabling development teams in a secure way. So Cloudsmith is an API first platform. We have excellent documentation, and it's built to help accelerate software development rather than get in the way.

That's a little bit about who we are and how we think we can help some of the challenges you might see in the market. But rather than take my word for it, I'm gonna hand you over to my colleague, Dan McKinney here. And as I said, Dan, I can talk about artifact management all day. But, Dan, why don't you show us a little bit about how this actually works in our

platform? Sure.

Thanks very much, Paul. So, yes, [00:06:00] let me just share my screen, and we can get started. So you should be able to see my screen now. So I promise that I do not have another slide deck here at all. This is just a a a primer slide before we get into the platform itself.

Of course, we are also happy to take questions. So this is live. We are live. We're happy to take questions. We have someone moderating the chat.

And whether you do your questions now or afterwards, or if you want a bit of an in-depth look at any of the things we just touched upon today, we're also very happy to do that. Paul, you're absolutely right. I will talk about artifact management all day, so I will try and stay on time and keep some time at the end just to hand back to yourself for some closing comments. So without any more messing around, let's just start. So the Cloudsmith platform overview.

What are we going to cover today? So we're going to take a look at the Cloudsmith platform itself. We're gonna kick things off by looking at some simple concepts around users and teams and roles and [00:07:00] things like that. This will be immediately familiar to anyone that uses GitHub we follow a GitHub model there. Then after that, we'll we'll look at repositories.

Now repositories are obviously the core of an artifact management solution but that's only 1 part of what we did. We'll, of course, look at package upload and download. That's that's, you know, packages go up, packages go down as a joke that we make, but that's that's really, really what we do. And then we'll touch on some other things. We'll touch on policies and upstream proxies.

You may know those as remote repositories from other artifact management solutions. We'll also talk a little bit and and take a look at Cloudsmith's security scanning and some of the some of the visibility that you get with our audit and our access logs as well. So like I say, this is only a a sort of handpicked few topics here. There's much more than that and and we could prop, excuse me, we could probably do a session on any of these that that would be the same length as a platform overview. So [00:08:00] with that in mind, let's get started.

So we'll jump straight into the platform. So what you see on the screen now is my Cloudsmith organization, my demo organization. And as I say, this is where it'll be familiar to anybody that that uses GitHub. So the way you have repositories in GitHub, we've got repositories in Cloudsmith here. Of course, these are binary repositories for for packages, libraries, and artifacts, and container images.

Now before we actually delve into these these repositories themselves, let's just take a look at some of the things that exist at an organizational level on Cloudsmith. So, of course, the first thing you've got is is users in in your organization. So we have a bunch of users in my Cloudsmith demo organization. Here is myself, of course, as well. You can also invite other people to join.

You can use SAML single sign on. We support SAML with things like Okta or Azure Active Directory, and we can even map groups from your identity providers, your SAML providers into Teams on Cloudsmith. [00:09:00] So as I say, this should be quite familiar. Now the way you grant access to repositories and and other things on Cloudsmith is, you know, by virtue of a team membership or explicitly at a user level. So users and teams, quite important.

And probably more important is service accounts. So service accounts are very similar to a user, only they're not linked to a user's email address or real person. You will typically use them for pipelines, for integrations. So if you're publishing packages, publishing artifacts as a result of a build, It's a service account that you're going to want to use for that. We also support things like OpenID Connect.

Now OIDC, really, really useful, allows you to have your your pipelines like GitHub actions or CircleCI, allows you to have those request and access token, an ephemeral token that only lasts for an hour or 2 automatically expires. So you don't need to store that long lived service [00:10:00] account API key in your your your in your CI or CD platforms. So just worth pointing that out. Now I'm not going to go into a lot of detail here at things at the organization level. We could come back to all of this.

Couple of things I'd like to point out just before we move on to repositories. So we do support SCIM for provisioning and deprovisioning user accounts. That's when you grant a user access to Cloudsmith the application in your identity provider, that kind of account will be provisioned. Similarly, when you remove the Cloudsmith application in your identity provider from a user, their account will be deprovisioned. So that's very, very useful to keep track of things.

We also we also provide, you know usage metrics in the platform. So you can see how much bandwidth and storage your organization has used, and we show it, you know, in real time and also historically as well. So that's the basics. I will come back to talk about these policies here over on the left. Right?

We've got a few policies, and I'll come back to [00:11:00] that once we've delved into the repositories a little bit. Okay. So with that little overview of of an organization and what sort of settings you get at an organization level, let's now talk about repositories. So I have a few repositories that I have used here, and I play with my little demo organization. So I've carried out some tests.

And 1 of the ones I I usually use is this examples repo. So let's just take a look in there. Now as you would expect, this examples repo, it has a lot of packages in it. Right? So we'll just let it load.

There we go. Now the first thing you'll probably notice is that this repository is multi format. So that's that's that's a little bit different from other artifact management solutions that you may have seen before, you may have experienced before. So on Cloudsmith, when you create a repository, it can hold any mix of packages that you use or just 1 type of package. It's very flexible.

Okay? [00:12:00] So you don't create an MPM, you know, registry. You don't create a a NuGet feed. You don't create a Docker registry. You create a a multi format repository.

Now this gives you an awful lot of flexibility. Okay? It doesn't restrict you in any way. You can create repositories based on services or products or teams or or any any way at all, even based on environments like, you know, development, staging, production. So it's worth pointing out because usually when we show this, the first thing people say is, is, oh, look.

There's different package types in here. So we'd like to explain that upfront. Now some of these packages I have published myself, you can see, uploaded by Dan McKinney. Some have been fetched by Cloudsmith from a third party source on Upstream, and we'll come back and talk about Upstreams in a little moment. But this is the core view that you get.

So we can view all the packages in the repository. We can also view the packages by group, which is actually a really handy [00:13:00] view. It will group the package versions together for us and show us all the versions we've got of each package, including download counts and when they were published and things like that. So we've got lots of different views. We can even filter the views to just show just Maven packages if we wanted to do that or just Debian packages.

So you really get a a nice visibility on even though you've got multiple formats here. It's very easy to drill down and see what's happening. So okay. So that that's just what a repository looks like. Now how do we control access to this repository?

This is a private repository. How do we control this a bit? So as I said earlier, access is based on teams and users. Okay? So it's very easy to configure access controls.

There's no there's no difficulty to it. So we configure it for service accounts, so we can give our service accounts right permissions. We configure Teams as well, so we can give some of our dev or ops teams read permissions. We can make the owners of the organization, you [00:14:00] know, admins, and we can even, you know, configure specific users. So that's how you control access to the repository.

Now that's quite simple, and it is quite simple. And this can all I should also point out, this can all be controlled and configured programmatically via the Cloudsmith API. So we have a full API, and we also have a Terraform provider. But, obviously, just doing it graphically here makes for a better demo just when we're showing things, but we'll jump out of this in a moment. So before I go on with that, let's just take a look at how simple it is to actually create a repository and look at uploading a package, so so just see how quick it is to get started.

So it really is it really is as simple as giving your repository a name, so we'll call this 1 overview. We get to pick a storage region, but that's not for performance purposes. It's typically for compliance reasons, but you may have a need to store your packages in a certain place. So I'll go with the Dublin, Ireland. That's closest to me.

And we'll make [00:15:00] this a private repository, and we'll we'll create this now. So as I say, this is all live as well. None of this is is prebaked or precanned, so we'll just try it live and see what happens. So okay. So we now have a new repository in my demo org called overview and and it's empty.

This is an empty repository. So if I wanted to look for package formats, upload instructions, I could have a look here and say, oh, I've got a new repository. What happens? Like, the upload of Debian package, for example. Now we can do it right here in the web UI, but, you know, typically, nobody is going to do that really, but the options there.

But for a format like Debian, we provide a great Cloudsmith CLI tool where you can just do Cloudsmith push dev and your package and upload it to this repository. So I'll make Paul very nervous now, and I'll say, let's give this a go. Okay. Let's try it. Not scripted at all.

Let's see how that works. Let me just share my screen. I'll change my screen share, [00:16:00] and I will go to my terminal. And what

what better way to prove we're really doing this live? What could go wrong?

Oh, I know, Paul, but everybody likes a live demo, and they they do appreciate that it's done, you know, real. So let's try this. So first of all, let's check if I can authenticate. Okay? So we'll just check.

So who am I? Cloudsmith, who am I? Okay. Good. I've authenticated.

It knows me. I'm Dan McKinney. My API key is in my credentials file. It's all configured. So now I should be able to just go Cloudsmith push dev, and I should be able to say my demo work, and my overview repo, which I've just created.

And for Debian, we need to give it a distro inversion. So we'll say this is a Debian package for BoomZa. Okay? And and I have a little Debian package here. Okay?

So we'll give this a go. There's my file. It's uploading to Cloudsmith. Cloudsmith is creating a new Debian package, and it is now synchronizing the file. [00:17:00] Synchronization is important.

That's where we extract the files that are within the package. We look at the metadata. We put all of that into our database. We do the checksums. We scan it for malware, we do a lot of checks.

So that took 16 seconds as you can see there. Great. Okay. Let's see when I go back to my Cloudsmith repository what has happened over at Cloudsmith. So let's have a quick look here.

I'll share my screen. Okay. Now let's just go back and have a look at this overview pack, this overview repository and see what's in there. Now there we go. There's our Cloudsmith Debian example.

Okay? So that is now here. It has arrived in my overview repository. However, you will notice that this package has violated a policy. Okay?

There's a little flag here that says this package is is not good. This package is not friendly. So something has gone wrong here. There's been a policy violation. So let's look at our package for more information, [00:18:00] see exactly what happened there when I pushed this.

Now this package is in violation of a policy. Oh, it's it's it's got a license that isn't allowed. Right? This package is an unknown license, which is not permitted by the policy, So it's been automatically quarantined. This package cannot be fetched.

So this is a really good point to just take a step back and go and talk about policies. So we showed how to push the package. The package has been called by 1 of our organizational policies. Now we'll go and look at that now. I did mention them earlier briefly when we looked at organization settings.

So here's our different types of policies. Authentication policies, license policies, vulnerability policies, and package deny policies. That was quite a mouthful. I'm not gonna go through them all in in in extreme detail. Let's look at the 1 that triggered that quarantine action for my Debian package.

So that was a license policy. Right? This policy is set to block AGPL licenses, but the key thing here is it does not allow packages [00:19:00] that are missing a license. And as an example of horrible packaging, that Cloudsmith, Debian example package I made, I did not include a license in it. So that was caught by this policy, and it was blocked.

Now that's a fairly simple policy. Where things get really interesting is where you look at other types of policies. So in our repositories here, if we go back, let's look at another let's look at another repository. We'll look at, like, this Azure DevOps repository. So I was building an example Python package in here.

Right? And you can see we've got packages in here where our security scans have detected vulnerabilities, And they've also violated a policy. That's a different type of policy. So let's look at this request package to see what's wrong with it first. So this 1 has violated a policy that quarantines high or greater severity CVEs.

Now if we look at the scan results, you can see that it does we've identified a high severity CVE here. And we we list the [00:20:00] version that we've got, version 2.6, and the version you need to go to to or, you know, to remediate that that that CVE. So this is this is just the the same type of action that the license, policy violation was. This package has been quarantined. I have to restore this package from quarantine before users can consume this package.

Now I'll show you what the vulnerability policy looks like that that caught this. So there's a vulnerability policy, quarantines higher, greater severity CVEs. We'll look at how that looks. So this policy only applies to my example repo and my Azure DevOps repo because these policies can be scoped, you know, to target specific repositories or specific groups of packages, even things like that very fine grained scoping ability for policies. So I've said if the, you know, if the CVE is greater than a high severity, to quarantine the package.

And it really is that simple. And I only have 1 policy here, but you can build as many of [00:21:00] these policies as you want within your organization. You can target different repositories with different levels of policy for quarantining. So, like, on a development repository, you could maybe quaran quarantine everything above, you know, critical. Right?

Critical and above. And on a production repository, maybe you want to quarantine everything above medium, you know, because you want stricter controls on a production repo. So you can build as many of these as you want. You can keep them all in 1 place. The final type of policy we have is a package deny policy.

Right? And that's very simple. If you have other criteria that are outside of licenses and vulnerabilities, if you just have organizational criteria, Nobody is allowed to use Log 4 j. Okay? You can block it here at a at a sort of, you know, a very strict sort of total block on the package.

So you can create effectively exclusion lists here that are are a way to control packages that come in. So I did a lot [00:22:00] of talking there. Right? And and that kinda was a whistle stop tour of of of policies in general. But where do these policies really come into their own?

Well, they don't really come into their own when you are sort of doing an example and pushing a demo package that that is designed to trigger these things that this was a very simple thing that I did. Where they really come into their own is when you configure an upstream proxy in Cloudsmith. So what's an upstream proxy? Well, over here. Upstream proxies are Cloudsmith's version of what some other solutions call a remote repository.

So think of things like PyPy for Python packages or Maven Central for Java or npm JS for Node packages. So they're effectively public package or third party package sources. Now it doesn't have to just be the canonical upstreams for each package format. You can configure out any upstream here. You can even [00:23:00] configure other artifact management platforms as upstreams here and pull packages from those in the Cloudsmith.

So what does it look like when we create 1? Well, let's see if we create a pipe in upstream. Well, I've hopefully just got the address for PyPI here. I'll put that in, and I'll just call this 1 PyPI so I know what it is. You can set it to just proxy packages, so just straight proxy them through, or cache and proxy.

Now cache and proxy is the more powerful mode. Cache and proxy means when you request packages that aren't in your Cloudsmith repo, we will go to PyPI and fetch them and store them in your Cloudsmith repository. We will do the security scans, the license scans, the malware scans, and you have that package now. You have a local copy of that in Cloudsmith. So if anything happens to the package, you still have your version in Cloud Smith.

So caching proxy is extremely useful. So let's just create this Python upstream and see what happens. Ah, great. Okay. So we've got now a Python upstream, and we know that it's got 10000000 [00:24:00] packages because Cloudsmith has gone ahead and indexed this package.

In fact, it was last indexed yeah, just today. Yeah. Indeed. Less than an article. So cancel that.

So it's ready to be used. It's ready to be you know, have packages fetched from it that we don't have in Cloudsmith. And that's a really common use case. Now if you think back to that other repo I showed earlier where I have multiple package formats, what's brilliant about this is that you can have multiple upstreams for different formats. So here's the upstreams that I have in the examples repo.

I have lots of upstreams here. And, again, all of the packages that are being consumed from these upstreams are going through our policy checks, our security scans you really get to centralize package consumption here. Now we do also differentiate in Cloudsmith between packages you've pushed yourself and packages that have come in from an upstream. So you can see some of them have this little tag here, [00:25:00] upstream, and the name of of the upstream that they came from. These tags are quite powerful as well because you can filter on any 1 of these.

So I can just say tag upstream like that in our search box, and I can just see packages that have come from an upstream. And, of course, like I said earlier, all of these tags, I could list all the packages in a repository with our API, but I can do the same query string here in our API. So it's really easy to sort and filter through packages on Cloud Summit, whether you've published them yourself or whether they have come from an upstream. So we've talked about users and teams, we've talked about repositories, we've talked about package upload, we haven't talked about package download. What happens at consumption when we're consuming packages?

And whether that's a user, a developer, or it is a build pipeline, How would you consume packages? Well, taking some of these packages right here into account, let's say [00:26:00] NumPy. NumPy is a super, super popular package. I think everybody uses NumPy. Let's look at the details we get.

So we fetch this from an upstream. We give you all of the checksums. We sign all packages with the GPG key, and you can provide your own, but we generate 1 for a repository anyway. And we we extract information. This is that synchronizing stage that you saw when I published the Debian package.

So we will extract, We'll parse out the version number. That's how we know this is, you know, strict semantic versioning, and we can apply the latest tag and all of that good stuff. You know, all of these classifiers have come out, the URLs, the platforms, all the metadata about a package. We'll also pull out the read me if it's got 1 for a package. Okay.

So we'll parse that out. We'll show you the contents of the package, the files that are within the package you can see here. And we'll scan it. Like I said, this one's clean. Okay?

So we'll scan it. We'll also if you've got other versions, we'll present them in the 1 place here for you to find. And [00:27:00] we'll also show the logs and stats about the package, who's been downloading it and the setup instructions. Now the setup instructions are the the important bit. This is how you consume the package.

So right now it's set up, and you can see we give contextual instructions here. You know, Dan McKinney, user and password. We can change the the authentication mechanism that we're using. We can change it to be my API key. The instructions will update in real time.

So we can see, oh, this looks really easy. We can just do pip install like you would expect for any Python package with our API key from this demo examples repo. So it's natively compatible, you know, with any sort of package format that we use, and that's the same across the board. So whether it is a NPM package or it's ah, yes. They will.

They will. They absolutely will. They will be sourced. That's a great question. So thank you.

These packages will be subject to the policy manager, Those those open source in fact, the policy manager is even [00:28:00] more important and more relevant to open source packages than it is to packages you publish yourself. I mean, we are not we're not we're not providing like, source code level analysis on these packages. So for packages that you build yourself, okay, that you have the source for that you are building, you can do all that good shift left security and scan them at source, but the beautiful thing is then you can also scan at artifact storage point here as well. So this is where you bring in the packages that everything you're building depends on. So it's really about drawing that thread of security from build through to packaging, through to deployment, through to run time.

And there's different tools that you need at each 1 of these stages, you know, but but having that at artifact management stage is super important. So yes. So as I was saying, just as an example, if you were to look at an MPM package and you wanted to know how to install an npm package from Cloudsmith, just like you would expect. So you come along, you configure your [00:29:00] npm RC file, you know, it has it here, you do MPM install. If you want to do, let's say, Docker, okay, so let's do set me up for Docker, There's you just do Docker login.

It's in the native OCI registry. There's nothing there's no real surprises here for anybody. This is this is what you would expect from an artifact management solution. Natively compatible, native publishing and and even like I did in the demo for packages like Debian that don't have a you know, there's there's no app to publish. You know, you can do app get installed and do app install.

There's no app publish. We have the Cloudsmith CLI tool for that as well. Now finally, because I'm looking at my clock and I'm starting to sweat a little bit here just before I do move on, there's lots we didn't talk about. So we didn't talk about artifact life cycle rules. That's automated retention policies.

We didn't talk about custom domains. That's having your own URL as the endpoint for packages, very important for branding. We [00:30:00] didn't talk even about our package delivery network and edge caching. We didn't talk about tokens or EULA's or GeoIP rules. There's so much more to explore here, and we would encourage you to do that with us.

But just before I do go, 1 thing I would like to talk about is visibility observability. So what do you get when you have centralized your artifact management? Well, the great thing you get is centralized logging. So you can have your audit logs for compliance. You can see who has been creating access tokens, moving tokens.

You can have package logs that show who has been pushing or quarantining packages. There is a package that violated policy and was quarantined. You get the access logs as well, so you get all the statistics and who has been pulling packages. All of these can be exported, so we can drop these out on a periodic basis. Or like I said earlier, you know, you can come into our API.

You can pull all the audit log entries for a specific namespace for a specific organization. So [00:31:00] it's really easy, and we have a very full featured API. There are lots of endpoints to play with. We also provide an API explorer here in our documentation. You don't even need to break out postman and configure things.

It's all ready to go right here for you. And a little note about our documentation, easy to explore at help. Cloudsmith. Io. No Cloudsmith account even needed.

Come along here, explore the docs, look at the upload instructions, you know, look at our integrations that we have. We have multiple integrations. We have a CircleCI Orb. We have a Bitbucket pipe. We have a GitHub action.

We have a Terraform provider. All of those first party tools are sort of natively supported on Cloudsmith. So without wanting to overload people with information, we have the integrations, we've got the API, we've got repositories, and there's much more we can talk about. And I'm sure you've if you've listened this long, you'll know that I am absolutely prepared [00:32:00] to talk about this endlessly for hours and hours. So absolutely come along and talk to us.

Should also say just before I pass over to Paul because I know we've only got a few minutes left of course, Cloudsmith, free to try, free trials, and a very small core free tier as well. There's no better way to experience it than to get hands on with the platform. So you can sign up at cloud smith dot com and immediately start creating repositories as quickly as I did in this demo and pushing packages as quickly as that. So I think I'll leave it there, Paul, and I will hand back over. I feel like I probably exhausted the good people that paid attention, so thank you

very much.

I thought that was super and so helpful. I I saw 1 of our 1 of our viewers has been praying to the demo gods for you and there's a cross fingers there. So I'm glad it all went well. Just a a couple of quick questions that came up that I think we might wrap, and I I know we don't wanna run for too long. Mhmm.

1 of the questions was around why is it important to have something that's cloud native and distributed instead of having a [00:33:00] server that you manage yourself? When would that be useful, and why

is that relevant? Okay. That is that do you know what? That's probably 1 of the best questions we could have.

So, really, we like to say that we are sort of the only cloud native artifact management platform. And, really, I can explain it really simply. The difference between cloud native and cloud hosted just means that when you sign up for a trial on Cloudsmith or you you you know, take us to Cloudsmith subscription, we don't spin up an instance of anything for you. There's nothing that we sort of have to do to provision there to to make the platform available to you. It's a fully distributed web application.

Just like GitHub dot com, when you sign up for GitHub dot com account, you know, you don't spin up an instance of that on a on a cloud host somewhere on, you know, Google Cloud or AWS. So Cloudsmith isn't sitting running on a little machine somewhere. This was the production Cloudsmith environment that we used for this demo. And my organization is there just like every other organization on Cloudsmith. [00:34:00] And, really, the biggest benefit is that that is fully managed by clouds.

So our team, our team of awesome engineers our SRE team, they manage the platform for you, and and you don't need to worry about replicating data across nodes for global availability. We manage the package delivery network that sits in front of it. We manage everything multi region. We take care of everything. So, really, it leaves you free to focus on packages going in, packages coming out, and applying those policies and and not worrying about the management overhead of artifact management.

So you don't need to sort of you don't need to become a platform administrator to use Cloudsmith. You know? So that's the biggest difference between cloud native and on an instanced version. You know?

So Yeah.

I think you got a a couple of really great themes. One's the management overhead. You know, it takes less effort to maintain because you're not managing a server, and [00:35:00] it's a fully managed service. The other thing that I thought was interesting in what you were describing is that it's a production environment from day 1. So couple of things resonated with me on that.

1 was that, you know, it's not like you know, you have a shiny new server and then you put 10000000 packages in it and suddenly it's a lot slower, which we know happens with, you know, with other technology. Yeah. If that if you add 10000000 packages, we won't even notice.

There's already many millions of packages in Cloudsmith, Paul, right now, today. And, no, exactly, it scales.

Right? It scales. Obviously, without going into too much detail because that's another whole session, the architecture of Cloudsmith, but it's built to scale. Right? And and it isn't it was never an instant application that has been adapted for the cloud.

Cloudsmith was built to leverage microservices, containers all the good sort of services the cloud providers provide nowadays. It's a just a more modern way of building an application. You know? That's it. I mean,

so don't take our word for it.

If you're watching [00:36:00] this and you're curious, we have a status page. We're We're very transparent about our uptime. And, you know, I think our historic uptime is over 99.9 percent and that's for all of our customers across our entire customer base. It's definitely worth checking that out. And he will post a link to that afterwards.

Dan, I'm just gonna move to wrap up because I think we we promised to be finished and we've got maybe just a couple of minutes left. So Yeah. I think

we said 40 minutes.

So so like I was saying with the status information, don't take our word for it. You know, Cloudsmith powers artifact distribution on the software development life cycle for some of the world's most innovative companies, You know, names that you'll know you know, companies like Shopify who just announced a whole kind of slew of product updates yesterday that had been powering their business over the last year, and and they use us across their entire software development organization.

But also for other use cases like software distribution where if you're a a software vendor and you have, you know, software artifacts that you want to put into the hands of your customers, you know, some of the features that we talked about there really make [00:37:00] sense as well. So if this is something that you think would be helpful, there's a a number of different topics that we'd be happy to talk to you about. You know, we'd be happy to do a health check or an assessment of your current posture in terms of your artifact management, your software supply chain, security. And, also, we're following up with this with the team where we've got a a number of webinars planned. I think our next upcoming session, Dan, is on the practical vulnerability workflows Yep.

Yep. Next week. That'll be featuring our VP of product Allison and our developer relations lead, Ciara Carey, who will be hosting and moderating that session for us. And then you and I will be back through the rest of the year and taking a deeper dive into some of these capabilities and talking about some of the kind of practical things that you can do. And Perfect by Magic, there's a a link to the to the next webinar.

So if you're curious about some of this we'd love to see you there. Feel free to follow-up with questions, and you know, we're always happy to chat if you want to reach out. Dan, did we miss anything today, or [00:38:00] does that wrap us up?

I think that's fairly good for a live webinar. I don't think we missed anything.

We obviously did leave out lots of parts of the platform, loads we didn't talk about, but always happy to do. So, look, we're genuinely passionate about artifact management, genuinely passionate about it, genuinely passionate about the product, and we love to talk about it. And we love to talk to people and and come and see how it works with us. Excellent. Well,

we'll leave it there because we'll be back next week, and looking forward to connecting with everyone again.

So thanks for your time today, folks, and looking forward to talking in the future. Thank you for

listening.