Live? Okay, great. All right. Welcome, everyone. Welcome to San Francisco, and to everyone joining online, thanks for spending the next couple of hours with us. Alex Kurtz from HashiCorp. Excited for the content that we showed you earlier today in the keynote and what we're going to run through in the next couple of hours. So before we do all that, I have to read from this piece of paper. Thanks, Jeff. In conjunction with our financial analyst day presentation, we will publish the deck you'll be seeing here today when you connect with us on our website at ir.hashicorp.com. This is a long one, Jeff. Today's presentation contains forward-looking statements, primarily on our current expectations and projections about future events and trends, the outcomes of which are subject to risks and uncertainties. These statements reflect our views as of today only and should not be relied upon as representing our views at any subsequent date. Forward-looking statements, by their nature, address matters that are subject to risks and uncertainties that could cause actual results to differ materially from expectations. Information regarding the foregoing and additional risks may be found in risk factors in our 10-Q filed with the SEC. During the presentation, we'll also discuss certain non-GAAP measures, which are not prepared in accordance with GAAP. A reconciliation of these non-GAAP financial measures to the most directly comparable GAAP measures, as well as how we define these and other metrics, is included in the appendix of our presentation and available on our website at ir.hashicorp.com. Thank you for hanging with me on that one. Real quick, here's the agenda for the next couple of hours. Dave's gonna take us through strategy and kind of the opportunity ahead for the, for the company. Armon's obviously going to talk about all the great products we announced today, and we're so excited about. We're happy to have Susan come on stage today and talk about go-to-market. And then, of course, Navam will finish it up, and then we'll get into Q&A. So with that, I'm going to hand it over to Dave. Cool. Awesome. Thanks very much. Thank you. Course of the day. I wanted to maybe just cover a couple of things. Just first and foremost, sort of what we're seeing in the market and where our priorities are, and then talk about our, you know, continued evolution of our value proposition and, you know, showcase that with some customers and use cases, and Armon will come in, give a little bit more detail about that. We'll come back and answer any questions people have at the end. I don't want to steal the thunder of what people are going to talk about, so I'll just say, basically, you'll hear basically three themes today from the different folks presenting. The first of those is I'll talk a little bit about the market. I would just say in a word, the market for cloud continues unabated. I think we all see that, but we are going through an optimization cycle. That's just the reality of where the world is. It's not reflected just in the cloud world. Literally, every software vendor is seeing an optimization cycle. This is just the nature of cycles, but the secular trend is undeniable, and if you talk to some of the folks that you will see at this conference, you will hear from them that they are trying to get to cloud as fast as possible. What they're struggling with is the how. They don't necessarily know how. Number two, you'll hear us talk about, and Armon in particular, about how we're continuing to make progress on this common chassis integrated value proposition that we telegraphed several years ago. Certainly through the IPO process, about how we're continuing to bring our customers to this cloud-delivered version of our products or our cloud-managed iterations of our products. There's both a push and a pull in the market on that one, as we always talk about. There's sort of the reality that people require a higher degree of trust at the infrastructure layer to consume managed services, and that just means that market moves slower than, say, the database market. Flip side is big companies are going in this direction, and we have evidence of it every single day. Super, super bullish on that, and we're continuing to build a product out to make that happen. I think lastly, you'll hear Susan talk about how we're continuing to simplify, you know, our go-to-market approach. You know, we solve complicated problems for complicated enterprises. And as we are engaging the, the, sort of the, the early majority of the market, you know, we're, we're having to simplify a little bit how we, we think about our go-to-market and how we talk about it to the, to the market more generally. Susan will talk about that. I just want to... I've done a couple of presentations today to different audiences, and I think one of the key themes is this one you see on the slide, which is we get to see how people are adopting cloud. We always say, like, when people come through Silicon Valley for their vendor tours, they go to Amazon, Azure, GCP, and more often than not, HashiCorp. So we're in that information flow of the same thing as the cloud providers are, because people come to us and say, "I'm going cloud. How do I do this? Help me do this." And our tooling, by and large, is the how they do this. And the mistake a lot of people make is just starting with the tooling, because the truth is, most organizations are going through a transformation in how they think about their org structure and how they think about the processes of adopting cloud, and that just means it's super early. Because if you just adopt the tooling, right, certainly there are new principles required around infrastructure as code and identity, et cetera. That's quite well understood. But you actually require a slight org structure transition. We've always talked about the notion of platform engineering functions. You will literally see that on the t-shirts here, because that's who these people are. The people that are here, by and large, are platform engineering people. That is our customer base. They are the ones championing these shared services inside their organizations. Often this is informal. It's not the de facto platform team for the company, but anybody that's doing cloud successfully is organized this way. And lastly, the world is going through this process transformation from, like, this ticket-based model of how they run infrastructure to this more, automated way, which every organization is having to go through. So this is what's happening in every company in the world, every single one of them. You know, what percentage of people are organized this way? I don't know. You should ask them, because it gives a proxy for how early we are in the market. I would say it's very, very, very, very, very early. When we go and talk to these platform engineering functions, we sort of like to, you know, contextualize where we fit in the market relative to the other things they're considering. I've talked repeatedly about every time there's a platform transition, how there's a sort of a software stack evolution as well, and that is happening across every category of the stack as the world is going cloud. I've been in this market for a long time, and this picture here is just the truth of how it works. There's the pre-production side on the left-hand side. That's basically the application lifecycle management problem, which is: How do I build an application artifact in the new way? Then there's the, "Hey, how do I run the infrastructure, what the infrastructure substrate looks like that I'm going to run that on?" That's the next thing along. Then there's the Security Lifecycle of those infrastructure and the applications upon it. Then on the right-hand side, you have the monitoring market. This is just how the market fits together. Not super, super complicated. We've shared various renditions of this, this view. Basically, this is a well-understood stack, and everybody in the world is going through a modernization cycle on it. On the left-hand side, you know, this is where GitHub, GitLab, et cetera, are participating. They're trying to help people shift to a modern approach to application lifecycle management. I happened to work for Microsoft years ago. They kind of invented this category with Team Foundation Server back in the day. You know, it's a few billion-dollar market in spend category, developer tooling. It's like, how do I build the application artifact? How do I promote it? How do I store the images associated with the application artifact? How do I make sure that it's tested, et cetera? That's a well-understood market. The entire world is redoing that market, and GitHub and GitLab are certainly pursuing that. GitHub is much, much larger than GitLab, but certainly both are participating there. On the right-hand side, you saw this, this modernization happen with application monitoring first. Datadog, et cetera, right? That's where they play, and it turns out actually, that market moved slightly earlier than the other ones because it was quite easy just to hook up the APM concepts to the new, the new infrastructure substrates, and those markets were addressed relatively early. Where we participate is in the Infrastructure Lifecycle Management and the Security Lifecycle Management. The interesting thing to me is this is where the lion's share of the, of the, sort of the, the market spend exists. It's at the runtime layer of the stack. This is literally the runtime aspect of your application. I may be building applications in GitHub or GitLab, but I run them through Vault and infrastructure provisions through Terraform, network with Consul. This notion of Infrastructure Lifecycle Management and Security Lifecycle Management is the heart of what we do. We have many products that participate in that, but fundamentally, those are the two problems that we solve. There's a modernization cycle going above, above this at the app layer for message queuing, right? People are going from multi-- TIBCO Multicast to Kafka Streaming. We all see that. At the database layer, they're going from traditional databases to, you know, Snowflake, Databricks, MongoDB, et cetera. Those things exist above us, but this is the heart of where we focus. I think, you know, if you take away nothing else from this morning's keynotes, you see that this is the problem that we solve. How do the platform engineering functions of the world modernize this approach here? Because everything runs upon it. What you see us really focusing on, and this has been going on for quite a while, is this notion of a single common platform. We've traditionally made our products available as self-managed products. You, you guys all know that. Because that's how the market wants to consume infrastructure. That's just how the market wants to consume it, because it's deeply, deeply serious to them. They run it on Amazon, they run it on Azure, they run it on GCP, but they want to run it themselves. What we have been working on now for 4+ years is how do we make this easier for kind of the early majority of the market that's now adopting cloud? Because the early adopters went quickly, they can self-manage this stuff. As the early majority comes forward, we have to make it easier for them, and this is something we've been talking about for several, several years. If you think about the actual products that underpin the Infrastructure Lifecycle Management, the standards in the industry, I use Terraform to provision the compute, I use Packer to provision the golden image on top of it, and I perhaps use Consul on top of that to, to update the service catalog as to where everything is. That's what every company in the world does. Today, we ask people to do that with self-managed software and wire that together. That Infrastructure Lifecycle is something that we can make much, much, much easier if we can run Terraform, Packer, Consul, et cetera, in a common chassis. The same thing is true of the security, the Security Lifecycle. The Security Lifecycle is about obviously machine to machine identity using Vault, but it's about people to machine identity using Boundary, because that's the equivalent problem they have. And then it's about the service mesh construct of how I secure with encrypted transactions or encrypted network connections between those two elements using Consul. It's incredibly well understood. This is not complicated to the platform engineering functions of the world, but the doing of it is hard because these are all self-managed products. I would say, as I said earlier, there's historically been a lot of conservatism about consuming infrastructure as a managed service, but we have tremendous evidence of that changing, where some of the very, very largest companies in the world are starting to move some of their workloads to HCP and our managed offerings. I just met with a big insurance company a minute ago that just... Actually, they presented in our leadership track, if you saw it. They moved from Terraform Enterprise to Terraform Cloud, and it took them 30 days. Like 2,500 work—3,500 workspaces, they moved from Terraform Enterprise to Terraform Cloud. This is a highly regulated entity that is moving their infrastructure to the managed versions of our products. Why? Because it's just way easier for them. There's lots of evidence of that. We want to be there as the market in general moves there, and we've had a huge amount of energy focused on the HashiCorp Cloud Platform. We think if we can make these available as a single platform for everybody, it massively reduces the skills requirement for the people that are, that are, that are tasked with, running and consuming it. It gives us the ability to actually provide much more complete solutions because we can actually, in product, nudge people to next product along, next use case along, without having the need for such heavy sales engagement. And most interestingly, we've actually made available this product in our commercial segment, so HCP, through a consumption billing model mechanism, right? And we see tremendous evidence that that is how people want to consume our products. They want to consume it as a single platform to automate the infrastructure cycle, the security life cycle, through a consumption billing mechanism, because these are platform teams that bill back to the consuming entities of the endpoints. So as I said, we've offered this single integrated platform to our commercial segment for some time, because we're just waiting for the comfort level of the bigger companies in the world to start moving this direction, but it's coming. There's a really, really good example of a customer. In fact, they're presenting tomorrow, if you're interested. It's a company called Singapore Press Holdings that is in our commercial segment, because I think it's just indicative of how this is happening. So, Singapore Press Holdings, obviously Singapore-based company, it's not a huge company. They engaged us about a year and a half and said: Hey, we use Terraform, we use Vault. We want to centralize that and run that as a SaaS service. What they did is they said, "Okay, I want to consume that in a consumption billing model. So basically, just let me buy some credits and I will apply them across the other state." They started actually on both axes. They started with Terraform for the infrastructure life cycle, and they offered Vault as a for the security access life cycle inside of inside of their organization. Almost immediately, they expanded to next use case along, next product along. So the logical evolution to my point is, we know exactly what this looks like. The next product along from Terraform is using HCP Packer to manage the image management life cycle. So every time you do a Terraform to deploy, I use Packer to orchestrate the depositing of the golden image of that infrastructure set on top of it. That is just how it works. We see it hundreds and hundreds of times every month. At the security layer, they started out with Vault, and then they ran, then they ran into it and said, "You know what? I'd really like to be able to use this common platform because it's a common billing mechanism, common access controls, et cetera, for the privileged access management problem." They consumed Boundary. They came back to us and said, "I actually want to now add Consul to that estate," and now they now use Consul as a part of their zero trust story, which I think is actually what they're talking about tomorrow, if people are interested. I think it's at about 2:30 P.M tomorrow. You can look for them on the agenda. It was actually accidental that they happened to be presenting. I just found out this morning they're presenting, so maybe it's kind of serendipitous. The value proposition is, of this is enormous because you can see how fast this happened, right? They doubled their ARR with us in about a 12-month period. Why? Because they were able to get up and running on next use case along, next product along, without us requiring huge handholdings. To me, this is just indicative of how the model will and should work, and we've been talking about this now for several years. As that market of the larger companies becomes more comfortable with it, you know, our platform offering has matured to the point where we think it's increasingly appropriate for the largest companies on the planet, and this is the model that we're moving towards. That being said, we are maniacally focused on winning the trust of the accounts that matter, right? The 4,000 or 5,000 thousand largest companies in the world are the ones where we are maniacally focused on building trust, because this is a big game of trust. This is a long, long arc of revenue opportunity if we can maintain the trust of the biggest infrastructure spenders in the world. Literally, we span every vertical, every horizontal. I was in Europe last week, meeting with everything from the world's biggest, you know, luxury goods retailers to the, you know, biggest supermarkets, to energy companies, to everything in between. They all are underpinned by our products. They just are, right? We have been focused, even though people are consuming it in a self-managed model, of winning their trust by winning the infrastructure life cycle and security life cycle for them, because they are at the infancy of their cloud programs. I couldn't do this session without giving a nod to AI, because you're all going to ask me about it. So maybe I'll just give my point of view on how we think about AI. Obviously, we introduced some capabilities in our products today, in case you missed it, that are AI-enabled, right? The ability to generate automatic test cases for your Terraform templates. That's kind of cool, using AI. The ability to ask ChatGPT or the equivalent inside of our developer portal to say, like, "Tell me how to do this particular thing I'm trying to do." Those are perfect use cases and illustrations of how we are using AI. We'll obviously be doing lots more of that in the future. But I would just say we are also a net beneficiary of AI, and I want to make sure that's clear. AI workloads run on cloud infrastructure. So not only are those vendors our customers, but actually it is driving net new cloud workloads, and we see it every day. Things like, you know, Terraform become profoundly important as people are provisioning compute on cloud, because guess what? GPUs are expensive. I want to be able to constrain the provisioning process on GPUs by creating a single control point, Terraform Enterprise, Terraform Cloud, that stops people from provisioning things that are going to get billed for. Super good example, right? So both cloud AI is both driving net new cloud workloads, which is super, super, bullish for us, but it also underscores the importance of what we do in constraining that process for cost control purposes. Here's an example of a global retailer that is allowing developers to quickly scale up their workloads using infrastructure as code, but you want to be careful of what they provision, because those GPUs are expensive. The second category is actually super neat for us, and this is one I think we're watching closely. Nomad is an enormously efficient scale scheduler. In fact, we had a 10,000 container—oh, sorry, a 1 million container challenge, maybe this was like five years ago, when we were doing a Nomad benchmark testing, of how Nomad could spin up 1 million containers across an estate, and one of the hedge funds came back to us and said: Well, we just did it for 10 million, so let me show you how that works. That high-performance computing use case has always been Nomad's sweet spot, and we are actually starting to see more than one instance of people using Nomad for the scheduling purpose across those GPU-based machines. Why? Because they're expensive. I want to make sure that I'm bin packing the workloads as tightly as possible, i.e., scheduling those workloads across that distributed compute fabric, because it's expensive. These are very, very scarce resources, and I think Microsoft shared just how much it costs them every time someone runs a query. I think it's indicative of it. So that's one we're watching. You know, that is not a unique use case, but it's certainly one that's important to us. Your only real alternative, I would argue, is something like a Kubernetes runtime platform. But Kubernetes is designed to be a, an application platform, not just a scheduler, so it's just not as well suited for that core scheduling use case. I'm happy to talk more about that, but I think the net, the net of it is, we're super bullish on AI and us as sort of a net beneficiary of the world's increasing use of cloud resources as it relates to AI. So as I said, we're gonna cover those three topics over the course of the, the next couple of hours, and happy to answer any questions after, after that. But for now, let me hand it over to Armon, and we can talk a little bit about some of the product specifics. Thanks. Thank you. Thank you. Awesome. Thank you so much, and thank you all for joining. I'm gonna build on a little bit of what you hopefully saw during the keynote and go a little bit into some of the product investments and how they sort of dovetail into a lot of what Dave was talking about. Great to see many of you in person. A lot of familiar faces that certainly we get to talk to on at least a quarterly basis. Is the clicker working? Okay, there we go. I think what you saw a little bit of the framing, both of the keynote and then sort of Dave, once again, you know, I think what we're trying to simplify the message down to is really the categories that we're focused on, one around lifecycle management, which encapsulates a bunch of existing products, the other one really around sort of secret lifecycle management. Each of these, there's obviously many tasks to be done, which translates into the many products of the portfolio, but they're sort of logically a part of solving, you know, one set of workflows. I'm gonna touch on and give a quick recap of some of the HashiConf announcements and just kind of talk about the impact that we see coming from each of those, right? I think, again, like I said, there's sort of these two clear categories for us. One is when we think about infrastructure, there's sort of a life cycle to that. How do you actually manage it, deploy things day one, manage it day two, keep it updated, patched, scaled, et cetera? So it's not just a set of day one challenges. That's what we often set out to solve with our community or open source versions, but then it's the commercial versions that really fill in that entire life cycle, right? So then we say, okay, how are we thinking about this not beyond just the day one? That's really where our commercial tools fill in that gap to solve more of a system of record and a full end-to-end life cycle management challenge. Similarly, when we think about security, it's a similar set of challenges. You might start by just saying, "Great, I need somewhere to put a secret." I might start with the Vault community edition. But when I think about that full life cycle and creating a consistent system of record across my whole estate, that's where we, our focus is really the commercial products. Now, with each of them, obviously, it's the multiple tasks to be done, so you just kind of saw it teased out in some of the demos. You might start with Terraform on the provisioning, but then say, "Great, how do I expose a higher-level developer interface?" That becomes Waypoint. How do I manage the underlying images that Terraform is consuming? That becomes Packer, right? How do I deploy applications at scale? That becomes Nomad. Each of these is part of a, sort of a logically interlinked portfolio, and that's where we see customers kind of go product to product, use case to use case. Taking a step back, I think for us, we think about what's that life cycle of a secret management, right? On the side of creating a sort of end-to-end system of record, when we think about the life cycle of secrets, you know, this is where you saw Radar come into sort of the announcements today, right? At the very top, the start point for a lot of customers is: Great, how do I even inventory and discover what all the credentials are in my environment, right? Often we've started with Vault, where we've provided the management solution for it to say, "Okay, here's a secret store. Here's a secret solution." The question for our customers becomes: Great, what's the journey of actually onboarding into it? I have 10,000, 50,000 secrets in my environment. I don't even know what they are, where they are. So that's where Vault Radar solves that part of the puzzle. It becomes an opportunity to land in these accounts, help shine a light on, hey, where's all your secrets sprawled in this environment, and then creates an onboarding path into Vault. So actually, we were just at our, our partner advisory earlier, and the conversation with our SI partners is this becomes a tool for them to help drive Vault adoption, right? Because oftentimes, great, you go in, you're deploying and standing up Vault, but then how do you actually figure out what the roadmap is to migrate the 50,000 existing secrets? Which applications do they belong to? Which systems are they in? This becomes an onboarding tool as part of that, right? It becomes a standalone product that we can sell, but more importantly, it's an accelerator into Vault adoption, right? Obviously, there's a whole bunch of work we've done around kind of core Vault, secret key management, et cetera. I think we saw some of the announcements, like bringing advanced data protection up to cloud. Really focused on bringing parity between the self-managed versions as well as the cloud-managed versions. Ultimately, it's about how do we deliver this full life cycle, you know, to our customers as part of the cloud platform, right? A bunch of different announcements here, all tied into that, right? Obviously, Vault Radar, key piece of that. Now in preview, we're gonna work with a handful of early customers. That's going into private beta kinda later this fall, and from there, we'll go into more general available early next year. As we go into kind of next selling year, should be a generally available product for us. The HashiCorp Vault Secrets product was sort of a, you know, it was a free beta. We announced that over June. That's now generally available, so there's public pricing. Customers can sign up, and basically move into that product. That has sort of a free tier, but then as they go through a, sort of a scale limit, moves naturally into a paid tier. That sits in parallel to our existing HCP Vault product. So HCP Vault, our more enterprise-oriented solution, managed single tenant for more of our security-conscious customers who don't want a multi-tenant offering, versus HVS or HashiCorp Vault Secrets, really more of a multi-tenant offering, lower entry point, more targeted towards the commercial customers, quicker on-ramp, allows them to get started with it and then can grow into the other offerings. Then the Advanced Data Protection, this is about bringing parity to a set of Vault capabilities. So when we think about Vault, it has sort of multiple modules, multiple use cases, the core being, you know, secret management. Often from there, customers then move up into key management, data encryption, data tokenization. That's an add-on module, so the ADP module is an add-on to Vault Enterprise and wasn't historically available as part of HCP Vault. So this now brings parity, so customers who are in HCP Vault can start with the core use case and then add on advanced data protection in the HCP environment as well. So again, kind of the key theme here is closing the gaps between self-managing cloud, really making it the cloud becomes more of the default landing spot. And then Vault Secrets Sync, you know, we talked about this as part of the keynote. The key value here is what we see from customers is they have a fragmented estate, right? They have, you know, maybe Vault on-prem in pieces or Vault in one cloud, then they might be using some Amazon Secrets Manager or Azure Secrets Manager or GitHub. And so the challenge becomes: How do I manage this in a consistent way? I want one pane of glass for all my secrets. I want one workflow for rotation. I want one way to audit all of it. So this is where we've seen a lot of demand from customers saying: Great, can you help me consolidate where I have a bunch of these different point solutions, use Vault as my system of record, and now I can synchronize into all of these other systems, but I only have to do my change management, my rotation, my auditing in one place now, right? So super excited about this. This capability will be both in the self-managed Vault Enterprise as well as HCP-delivered version. So then when we talk about Consul, two big updates there. One is the sort of locality-aware routing. So there's a bunch of other features that are part of 1.17, but I think this one is super interesting to highlight. It is an enterprise-only capability as part of Consul Enterprise, and the key value here is being able to optimize the cost spend for customers running, you know, multi-network traffic, right? So when you think about almost any enterprise deployment, you're either, you know, certainly one region, multiple availability zones, but most of them are multi-region as well. And so there's an additional penalty you pay anytime your network traffic goes between availability zones or between regions. You're sort of spinning the meter with your cloud providers at a much higher rate, right, in terms of what you're paying for network traffic. So this capability, the value of it, is they can still maintain these large deployments across availability zones or across multiple regions. So if, you know, something fails, and they need to, you know, make sure their service is available. But from a day-to-day perspective, you know, most of the time, you're not in a failure scenario. So if we can optimize that traffic and keep it within the availability zones, there's an enormous saving. We have, we have, one, I'll call it sort of a large-scale tech company in Southeast Asia. We worked closely with them on delivering, you know, building this capability. You know, in some sense, they drove a lot of the requirements for us. Their estimate is probably $3 million-$4 million a year in what they will be able to save just on cloud networking spend because of this capability, right? So that becomes the value, right? As these customers are able to roll this out at large scale, it's a multimillion-dollar save on what they're paying in networking by just optimizing how the traffic is routing, right? HCP Consul Central, we're super excited about. This opens up a whole new set of capabilities that are cloud-delivered for Consul. As we're trying to move customers from self-managed to cloud, this is kind of a key part of the hybrid strategy, right? We're gonna deliver net new capabilities like HCP Consul Central only through HCP. It's an HCP service, but what you heard me highlight in the keynote is it's not only applicable to HCP Consul, right? I can be a self-managed Consul customer that's running in my own data center or in an edge deployment in a store, a factory, wherever. I can also be running in cloud, or I can use HCP Consul, and all of those can then integrate back into Consul Central. This provides a way for us to start taking customers that maybe were purely self-managed, get them to start on a cloud journey with us, and consume an additional level of capability, whether, you know, in this case, it's observability, it's lifecycle management, and a set of integration APIs, which allow us to do richer integration with, you know, our ecosystem of technology partners. Shifting gears a little bit to the infrastructure side, lots of announcements across the board for Terraform. It's been a busy season for us. I think, you know, kind of going through them piecemeal, the first one is sort of testing and some of the generative AI use cases, right? If I take a step back, I think, again, we have two core audiences in most of these accounts. It's the platform teams, who often are our buyers. They're our kind of core user. They're bringing us in, but their job is to enable a set of application developers in these organizations, right? So I may have one platform team supporting hundreds of various application teams. So the goal is these small teams, these platform teams, how do we give them more leverage to operate at scale? And so part of it is how do we make them more productive, right? So the testing features is a key part of that. It allows them to make sure that their modules are well-tested against a variety of edge cases, 'cause otherwise, what happens is application teams end up exposing those edge cases, and then they need to get involved, and it's a manual process. And then leveraging some of the LLM technology, it's making it easier for them to automate the creation of those tests, right? So we can kinda look at their definitions, look across, you know, many hundreds or thousands of other similar definitions, and then suggest, "Hey, okay, these are edge cases you might maybe haven't tested for as part of your module," right? So I think there, we're trying to look at where can we apply some of these LLMs in very targeted ways, really focused on where do we deliver productivity gains to the users. Now, I think what's interesting is because of the compute required to do some of this stuff, it can only be delivered as part of our Terraform Cloud offering, right? So this becomes sort of a carrot for customers to, A, move from sort of commercial... I'm sorry, the community versions into commercial, but even if you're a Terraform Enterprise self-managed customer, it's a carrot to move to the cloud version, right? Because very few customers would accept it if I said, "Hey, to use this feature, give me 3,000 NVIDIA cards," right? So it becomes sort of a customer's understanding. Yeah, makes sense. If I want that feature, I have to move to Terraform Cloud, right? And I think you're gonna see more of that, particularly with these AI capabilities, where it becomes a carrot to move the customers onto the cloud product. The next one is ephemeral workspaces, and I think what we end up seeing is, in many of our largest customers, an enormous part of their cloud spend is dev test, right? So you might say, you know, in some cases, as much as half, right? If 50% of my spend is production, the other 50% is development and testing environments, and there's just a tremendous, tremendous amount of waste that we see in the dev test environments, right? Oftentimes, it's developers spinning things up that are way larger than they need. Instead of it being a small, you know, instance, it's a quadruple extra large because they thought it was cool, right? Or you just see things like, "Hey, I'm bringing it up for a test." The test runs for 2 hours, and then I leave this infrastructure running for 6 months, right? Or you have developers who leave, projects that are spun down, and all this stuff just gets left running in the cloud, right? Until someone comes through and does an optimization cycle. So the capability here, the ephemeral workspace, is really looking at how do we solve that in a bit more of a programmatic way, right? To enable those platform teams, rather than going and chasing it in a one-off way and trying to kind of play Whack-A-Mole. So the goal is, through a policy-driven approach, you can apply it and say, "Great, everything going to my development and testing environment, if it's part of an automated CI test, great, at maximum, it lives 24 hours. So great, it gets provisioned through Terraform Cloud, then we go, and we automatically clean it up 24 hours later." So you don't have to depend on a developer having the discipline to come back and clean it up themselves, right? Or I might say, "Great, you can ask for a developer sandbox. I'll give it to you in an automated way. It lives for seven days, and then I clean it up." So really looking at, for our customers, how do we help solve this problem for them of, I kind of have this runaway spend in dev test, and asking my developers to be disciplined about it is not, you know, particularly effective, right? So you have to apply a more policy-driven, automation-driven approach to it. The other big one is Stacks, so I'm super excited about this capability, right? This is, you know, as I mentioned, probably the biggest enhancement to the Terraform sort of core engine, since it was released. Terraform, for a very, very long time, understood single workspace, single environment orchestration at a time, and then we've built various layers of tooling, and there's random scaffolding to kind of do multi-environment orchestration. But what Stacks does is now make that all first class as part of Terraform. So now Terraform understands, great, I might have 10 regions as part of production. I might have 15 layers of my stack that all need to be orchestrated at the same time or sort of in sequence. And so now you can kind of describe to Terraform all of those components, all of those different parts of your environment, and now it can orchestrate through a stack in an automated way. And this starts to apply—let us apply policy, where, great, I have to go through development before I can go to testing. I have to go to testing before I can go to production. It lets us automate that workflow, where before it was a lot more sort of, you know, a little bit, you know, more duct tape and glue on behalf of users kind of having to piece some of this stuff together. Now, I think some of the interesting implications here is this is a capability we've been working on for, you know, well over a year. It's a very core change to Terraform. You know, all of this is going to land in Terraform post the BSL license change, so this is capability that will only live in Terraform and not be part of sort of any variance of Terraform. At the same time, this capability is sort of split between what will live in the community edition, which is the ability to define these Stacks and its various components, but then the core engine that can actually do some of this multi-environment orchestration will live as part of Terraform Cloud and Terraform Enterprise. So simplistic use cases can live in the community. You can define the Stacks, but if you want to do the more complex orchestration that our larger customers will require across multiple environments, multiple Stacks, there's a core component of that that requires the Terraform Cloud, Terraform Enterprise backend, right? So we're super excited for a number of reasons. I think it drives a bunch of innovation on the core Terraform engine. It's a big leap since, you know, basically over the last eight years of its execution engine, but also has a very strong tie-in to the commercial product, and we think will be a good driver of customers having interest in moving from community and custom-built scaffolding over to the Enterprise versions. Then the Run Tasks are, you know, we're constantly expanding our ability to sort of integrate external pieces into the Terraform workflow. So when we think about Terraform, it's ultimately a workflow orchestration tool. There's many important phases in that life cycle, right? And so, as you can imagine, we have many partners we work with, Palo Alto Networks and, you know, Snyk and, you know, pick your favorite, right? GitHub, ServiceNow, et cetera. So there's many life cycle points where these folks want to work with us to say, "Okay, great, every time Terraform makes a change, my ServiceNow CMDB should be updated. Every time Terraform does a plan, I want to apply policy through Prisma Cloud." So these Run Tasks become a critical part of how we integrate with them, and they also become a key part of the commercial value prop, right? So great, if you want to go create your own custom integration with Terraform open source into Prisma Cloud, you're welcome to. You're gonna have to maintain that as Terraform and Prisma's APIs evolve. Versus if you're using Run Tasks, this is a formal partnership. You know, it's an API that we build and maintain and partner with folks like Palo Alto to maintain, and that becomes a key part of the ecosystem and value of moving to the commercial versions, right? 'Cause most of these folks, their infrastructure doesn't live in isolation, right? They have security controls they have to implement. They have change management through ServiceNow. They have cost management tools, et cetera, and this provides a first-class way for those integrations to be done. Then kind of continuing on the trend of infrastructure life cycle, I think the key thing we've been seeing over and over, right? The biggest gap to consumption of cloud is a skills gap, right? And so we often see this. We talk to our largest customers, and they'll say, "You know, great, I have 10,000 developers. 2,000 of them know what cloud is. What do I do with the other 8,000, right? Like, I'm asking them to build cloud applications. They don't have the skills to do so. So how do I actually get them there? Right, and so one answer could be, go train the entire world on, you know, on tools like Terraform. I think that tends to be, you know, a difficult path when you have a developer community of 10,000 people, right? It might be practical to train 1,000, 2,000 people in your ops function, but in the same way, you don't expect every single person in your organization to become a vAdmin, right? You know, said, "Okay, great, I have a set of people that are VMware trained and certified. They go and manage the VMware cluster. I don't have everybody certified on VMware." I think there's a similar pattern required, but I think the difference is people don't want to go through a ticket-driven ITIL workflow, right? So how do you still deliver that DevOps experience without having everybody have to go now be sort of a, a cloud expert? So this is really where the repositioning of Waypoint and the tight integration of Terraform comes in, right? Our view is we want to enable the platform teams to define that set of golden patterns. They're gonna do it using Terraform, and then expose that to the developers in sort of a, a high-level way, where they don't have to know the details of infrastructure. They're just coming in and saying: Great, I want to deploy a Java app to Amazon or a C# app to Azure. I don't really care about the details. My platform team should figure it out, right? So that golden pattern gets defined through Terraform. It gets exposed as a set of templates through Waypoint, and then where this goes is it's a set of actions and workflows that we get exposed on top of that. So if the developer says, "Great, I have a Java app, I might need a workflow to build the app, deploy it, do a rollback if something goes wrong. I don't care how that works. My platform team should define it and own it in conjunction with security, in conjunction with compliance."... to make sure these workflows are vetted, right? Our goal ultimately, though, is to simplify the consumption model, both for our tools as well as for the customers going to cloud, right? So that's where we think this stuff becomes an accelerator, right? If the gap is a skills gap inside these accounts, one answer is go train 10,000 people on Terraform. Another answer is make it so they don't have to learn Terraform at all, right? And that's really the path we think is, is the logical one, is train your platform team, get them up to speed, and then enable your developers. And we think that becomes an accelerant to both our product adoption, 'cause now Terraform is being used implicitly by the developers, but they don't have to directly interface with it. And at the same time, it becomes an accelerant to cloud, right? And so we've had some great conversations at our Partner Advisory Board about exactly this. This is a pattern we see across the board. It's not just a cloud problem, right? You know, we're talking with database vendors whose challenge is: Great, I have developers who want to consume my MongoDB database, let's say, but their challenge is they don't know how to provision that database. So how do I make that easy? And so you can see where there's a super logical partnership. We say, "Great, expose MongoDB as another golden pattern that can get consumed through Waypoint." That's how we start unblocking these consumption problems, right? 'Cause at the end of the day, the developers care about, "I wanna use this service. I don't care how it's provisioned, I don't care how it's managed," but that detail matters today, right? They're sort of put in that firing path. They have to figure it out, and that becomes sort of a blocker to consumption. Nomad, we continue to be super excited about, right? I think you saw the sort of cheer from the audience. It has a loyal and growing, growing fan base, and I think one of the interesting things has been, you know, AI driving some very interesting use cases for Nomad. Obviously, its strengths are very large-scale, low-latency scheduling. In kind of a world of sort of low-scale microservices, people might have picked something like Kubernetes. When you start talking about, "Hey, I have to have thousands of GPUs, and I care about, you know, how much—how efficiently am I leveraging them?" Then speed of scheduling and scale of scheduling become very important. We've actually seen a number of interesting adoption use cases now around Nomad. Dave highlighted one of them, where that's exactly the driver of it. Great, I can put Nomad on top of a fleet of several thousand machines and quickly go consume all of that. We're super excited about seeing sort of that pattern. I think in general, what we're seeing is management complexity of Kubernetes is leading people to explore more and more Nomad use cases. I think that, you know, we're gonna continue to see that, right? I think there was sort of a period of, you know, throw unlimited headcount at these application teams, and so you saw the sort of Cambrian explosion of tooling. Yeah, I think now as people are saying, "Okay, but what was the ROI? Are my developers actually more productive? You know, is running 500 Kubernetes clusters actually sensible in an enterprise?" Maybe the answer is no, right? So we're seeing people kinda hit that and say, "Okay, actually, I can run three Nomad clusters centrally as part of a platform team. That's just a shared service to my app teams who shouldn't know what Kubernetes even is." You know, and that's a much more efficient way of delivering this. And then similar, HCP Packer, just like the run task story around Terraform, it's a similar life cycle there around many partners who want to enforce, you know, security checks, compliance checks, you know, central registry, et cetera. So there's a whole life cycle around Packer, around image building, revocation, metadata management, and so we're adding a set of Run Tasks there that allows us to have first-class partner integrations around Packer as well. And becomes another opportunity to move sort of open source Packer users into HCP Packer, where they can leverage these first-class integrations. You know, ultimately, I think taking a step back, you kinda saw this in the demo we, we sort of did at the end of the keynote. The goal is what we wanna deliver a sort of a single logical infrastructure cloud, right? Looking at, great, if I'm delivering a production-grade multi-cloud, you know, service as a platform organization, how do I do that in a way that's gonna be high leverage for me as a platform team, that's gonna be simple for me as a developer team, and secure, so my security and compliance groups are gonna sign off? Within that portfolio, our view is there's multiple insertion points into these accounts, and there's multiple tasks to be done, but ultimately, it's a journey that you're taking a customer on. They might start by saying, "Great, I have to deploy and manage some infrastructure," so it's a Terraform problem. Or, "Hey, until I can secure my credentials for cloud, I'm not gonna open the, you know, the door," so it might be a Vault start point. But from there, our opportunity is to win a position of trust and take them on this journey across the products and really solve the next problem, run next problem along. And if we can deliver it as part of a common chassis through HCP, that's gonna simplify the overall motion, right? And so that's really where sort of our focus area is, is really investing in some of those non-functionals, right? Building trust with enterprises through better disaster recovery, better SLAs, you know, a European region, PCI compliance. All of those things you're gonna see come from us to really make that sort of an investment in the trust that these enterprise customers sort of expect from these cloud platforms. And from a product perspective, it's a closing of the gaps, so there's parity between self-management cloud, and then, as you're seeing with Terraform Cloud, actually a superset of capability, right? You want the AI testing features, you gotta be on Terraform Cloud. And so over time, the products actually superset into cloud to drive that adoption there as well. And that kinda pulls it all together. I will, from here, hand it over to Susan St. Ledger, who's gonna share her view on worldwide field operations and go-to-market. Thanks so much. Hello. Thank you all for being here. For those of you who I haven't met, I thought I'd spend a little bit of time giving you a little bit about my experience. I know there are some familiar faces in the room from my, my past companies for sure. Then I'm gonna spend time on talking about increasing customer centricity and a faster path to success through rigor and simplicity. So in terms of my background, rather than going through the entire history, I thought it would be most interesting to pull out the patterns that I think are most relevant to HashiCorp. First and foremost, all the companies I've been at have been high-growth companies at scale, and I've seen many different inflection points, whether it $1 billion-$22 billion at Sun or $100 million-$8.5 billion at Salesforce, $670 million- $2.5 billion at Splunk, or $800 million - $1.8 billion at Okta. I've seen many different inflection points, and I think there's a lot of experience there that I can draw on for HashiCorp. The other thing about Splunk, of course, is we went through a massive cloud transformation. I love it when Armon stands up and gives us his vision on the cloud, and of course, we've made tremendous progress, and I'm very, very excited about helping drive that transformation based upon my experience in the past. Salesforce, for me, there are many different patterns I can draw on there, but the one that really jumps out at me is we focused on lifetime value versus short-term revenue. And the reason why I think there's such a good parallel here is because when I got to Salesforce in 2004, everybody was still telling me, "You're crazy. You're an enterprise sales leader. The enterprise is never going to the cloud." That was 2004. "It's never gonna happen. You're crazy. What are you thinking?" And so what we said was, you know, it was a very early market, and it was maturing, and so we needed to take that mindset of lifetime value. Mark used to always lean on this, this one Bill Gates quote, which said, "You always overestimate what you can do in one year, and you underestimate what you can do in ten." That I completely agree with, and it was... We had the proof points, right? When I got there, I think the ASP was somewhere around $67,000, and eight years later, my strategic team did multi-year, multi-year deals for $80 million, $123 million, and it just kept going on from there. I really do see a parallel with the market and how the market is maturing here to become a market like that. Lastly, if I draw on the experience across all of the different companies that I've been at over the course of my time, it's there is always room to increase the customer centricity. I want to talk a little bit about what that means to me and why I think that's gonna lead us to a faster path to customer success, as well as HashiCorp success. So customer centricWhen I talk about customer centricity, I want us to really lean on what we know to be true, which are the secular trends that you heard Dave talk about. I mean, customers are going to cloud. Nobody is denying that. They want a singular program, and they want a singular platform. And so, but when they're adopting the cloud, there is this new reality of this new operating model that we, of course, call the Cloud Operating Model. And so what they need to do now is focusing on solving the problems that make the Cloud Operating Model more efficient. Our role now is we're past the early adopters, and we are now in the early majority. In order to make those people successful, we need to increase our customer centricity by meeting them where they are. What that means is we need to be far more prescriptive. Our go-to-market to date has been deeply, trenched in technical value, right? Product technical value. While all of that value is still true, it's too complicated for this next part of the market. We've learned what our customers are trying to buy, right? They want to buy that integrated platform that Armon was just talking about, and they want to focus on solving two of the major challenges that come along with the Cloud Operating Model. The first one being provisioning and management. That's obviously introduced by the Cloud Operating Model. Day one, the build-out of infrastructure, and then day two, operations management and drift detection. They need to solve the new security and access challenges because firewalls no longer exist. How do they think about the world in, in terms of identity-based trust? What does that look like in the new estate? We're going to market with these solutions of Infrastructure Lifecycle Management and Security Lifecycle Management on an enterprise-ready platform. When you talk about enterprise-ready, it's all the things you would expect from an enterprise cloud platform. It's automation and optimization, so the management capabilities, if you will. It's visibility and policies for what we call little C compliance. It's reliability and scale for our largest customers, and integrations and APIs, because we know that we are at the center of the shared services of all of our customers. And so that's incredibly important for us to have the deep integrations with the technical partners that Armon just talked about, as well as prolific APIs. And then, of course, we need to deliver the governance, risk, and compliance you expect of any enterprise cloud. So the simplification is one platform, two conversations, and we really do believe that's going to drive go-to-market efficiency. But what does go-to-market efficiency mean to me? Well, first and foremost, I think most of you are familiar with our adopt, land, expand, and renew model. We need to generate more predictability throughout the sales machinery with that model. We need to continue to reduce the time to land, and I'm happy to say that we're on track for our first half net $100,000 ACVs. I think Navam usually updates you on that. Against our annual target of $80,000-$100,000, we're on track for that. And then we need a faster path to customer success. So quicker landing, quicker time to value. But that's all set. Easier said than done, right? So what's the answer to how? How are you gonna do this? Well, before I arrived, the team had begun to crack the code on how our customers really walk through our maturity model. And we've done deep assessments on what they're doing, and we have very strong opinions on what's making our most successful customers successful. What's the fastest path to success? So for instance, the walk from Vault through to Boundary and Consul, so Vault being secrets management, and Boundary and Consul taking you all the way to Zero Trust. And there are many of those patterns throughout our maturity cycle, and all of those patterns have begun to galvanize. And so what we need to do now with our field and with our customers is to tell them what they should do, not what they could do. And so let's take a look at a customer example, perfect customer example. So this is a global auto manufacturer, and it's a classic progressive adoption of Security Lifecycle Management. So ultimately, they delivered a shared service of secrets management, and gradually got to a true Zero Trust environment throughout their entire environment. But where they began was with a small $250,000 land. They started protecting some secrets for their apps team. The next thing that they did was they started to continue that walk, taking more estate under that, and they basically took it to all of the applications developers teams, the app dev teams. And then they began connecting with Consul through service mesh. So it's a cycle that continually repeats. We can't be afraid to land them, land them small, and then continue to grow them. What they did subsequently that got us up to a $4.7 million lifetime value to date, is they just repeated these cycles. They took new estate under management with Vault, such as their manufacturing line and their assembly lines, and then they started bringing in new secrets. They started managing certificates. So through this process of protecting, connecting, and enabling in the inspecting of secrets, our value continued to increase more and more with them, as well as our strategic position. Their future aspirations, they're actually in the process of looking at Vault to for their connected car platform. So we're excited about those conversations as well as they're talking to us about Infrastructure Lifecycle Management, so Terraform throughout. We see this pattern repeated over and over again. And here's yet another proof point. So I think you've, you saw... You see this slide once a year at this conference, and it's a similar story for our top 10 ARR. This has been steady expansion over the course of the last year, and we see this, the lifetime value, just continue to go up. It continues to drive our position and our confidence in the fact that lifetime value is the right focus here, and it is about helping them through this maturity curve. Aside from the ARR going up, the other thing that should jump out on this slide is that the multi-product mix is going up as well. So last year at this time, on these top 10 ARR customers, we had three out of 10 that had three products, that were using three of our products, and this year it's seven out of the 10. So once again, just a great proof point of the fact that our customers continue to mature and the lifetime value is there. And that's what we believe is going to be the long-term benefit for this company. With that, I'll turn it over to Navam. Thank you. Thank you very much, Susan, and welcome everyone to HashiConf. It's great to see you all here, and also, a warm welcome to everyone who is, consuming this online as well. I think I've met a lot of you before, but just to reintroduce myself, my name is Navam, the Chief Financial Officer of HashiCorp. We covered a lot today. Dave and Armon talked a lot about the work that our R&D team is doing in delivering our integrated platform and the acceleration we expect, with this integrated platform. You just heard Susan, here talk about some of the work she's doing with our GTM simplification and the strategies he's running with GTM simplification. On the finance side, I'm just gonna touch on four quick slides, and then we'll get to what everyone here is excited about and I'm excited about, which is the Q&A session, where we get to answer a lot of the questions that you have. I know all of you, or a lot of you, and I know you all have a lot of questions, so I'm looking forward to that. From a finance perspective, we are firmly focused, or we firmly remain focused on the fundamentals, right? I want to take you back to this slide. This is a very familiar slide to you. If you attended HashiConf last year, the Analyst Day last year, you saw, you know, this slide. We- when we talked to you during the analyst... Sorry, the IPO, you saw this slide. The fundamentals we are focused on are, first and foremost, our 100,000 customer set, right? And we are continuing to execute against our plan to grow this 100,000 customer set at the target rate of $80,000-$100,000 a year. I'm pleased to report we're on track for that. Last year, we landed at close to 800 customers. For the first half of this year, we've landed more than 50, and we expect that we will continue this momentum in the back half of this year and be above our plan of the 100,000 customer set that we expect to land. And back to what Susan was saying, right? Like, this group of customers are the bedrock of our revenue. Not only does it represent the vast majority of our current revenue, every one of these 100,000 customers have exceptionally large long-term value for us, and we expect that the future revenue that we have will be made up with a, with a lot of these 100,000 customer growth as well. So very glad to see the, the, the performance here on the 100,000 customer set and continuously, you know, getting penetration in the G2K and the G4K and seeing that $1 million customer set increase as well. So that's fundamental number one that we're focused on. Fundamental number two that we're focused on is, is on our margins around cost leverage, right? And there are two aspects to this. There's our gross margins and our operating margins. So on the gross margin side, we obviously have this tremendous advantage, and that is that we are a very high gross margin company, and that's, that's an advantage off the gate. So our priority is to defend this or, or maintain these high gross margins. Our self-managed products have high margins to begin with. Our cloud products, we're showing continuous increases in our margins over time. We started off with close to zero, when our first cloud, cloud revenues came up a few years ago, and then we've been ticking that up quarter over quarter, year-over-year. Most recently, we got to about 66% of, 66% gross margin on the cloud side. We remain well on track to get that up above the 70% range with a long-term target of being in the high 70s. So maintaining that high cloud margin as more of our, our revenue go to cloud, will be able to... Will, will enable us to maintain the high margins that we expect. So that's number one on, on the, on the gross margin side.... Then similar story on operating margins. We have high gross margins, so then we get to profitability by, by focusing on leverage on the operating margin side. 2022 and 2023, we've made substantial investments into the company, as you all know. Starting around the middle of 2023, in the second quarter, we saw that story of of leverage start to play out. We had 32% margins, and this -32% margins in the second quarter of 2023. We've started to show that leverage quarter-over-quarter. Most recently, we ended at negative 19% margins, well on track from what we said we were gonna do. This upcoming quarterly guidance, we expect to be at negative 17% margins. So you're seeing this momentum growing of us delivering quarter-over-quarter margins and moving this down to breakeven. Similar story on the EPS side as well. Second quarter last year, we had -$0.17 of EPS, and this last quarter, we ended up at a $0.06 loss, and this upcoming quarter, our guidance is to end at $0.04. So we are starting to prove the leverage story that we talked about over the past couple of quarters, and we expect this leverage story to continue. So I'll end with how this comes together and how we view our long-term model. We're in this period of cloud optimizations, but all the conversations we're having with our end customers point to one thing, which is that they are continuing to move to cloud. They're continuing to prioritize app modernization, and we expect our long-term targets to remain the same as what we talked about last year. The goal is for the integrated platform and the GTM simplification to continue to drive momentum with the 100,000 customers, enabling us to get to our goal of $2 billion-plus in top-line revenue over the long term, and then the leverage cycle to continue from this quarter onwards to get to 20%+ operating margins and free cash flow margins over the long term as well. We talked about the medium-term outlook here, and in 2025, our expectation, again, to reaffirm, is to get to breakeven by the back half of 2025. And given what I talked about in the previous slides about the margin leverage that we're showing, we are confident we'll be able to get to that breakeven target in 2025. Free cash flow will be ahead of operating income breakeven, and non-GAAP EPS will be ahead of free cash flow. So our expectation, again, is to get to breakeven in 2025. So with that, let me end and get to Q&A. We, we continue to remain very excited about the potential of this company, and we, we also believe that we're still in the very, very early stages of what we could become, and, very excited about executing on the next several quarters, getting to that breakeven plan and the long-term, target. So with that, let me pause, and we're going to take a quick break. Okay. So we can, get back to Q&A. Thanks very much. Yeah. So we're running a few minutes ahead of schedule. I think what we're gonna do is, because we're so efficient here, 2:45 P.M. Pacific Coast Time. So I'll give you guys, like, a 15-minute bio break and get some coffee, right? And then, we'll do Q&A. Sound good? All right. Here we go. Let's get back to our seats. Yep, one second. You can't even have. You can't raise your hand yet. We haven't even started yet. ... So you know the kind of questions we want, right? Okay. Let me just kind of... Okay. Okay, I'll raise you. All right. Okay, cool. My voice sounds- All right. Is this on? Yep. Okay, fantastic. Got my Diet Coke, not my Diet Pepsi. Where'd you get that? Anyone else need a Diet Coke? They took the labels off, so there's no branding. Sponsored by. All right, are we live on the stream, Jess? We're good? Okay. Well, all right. Back, we're back for Q&A. We've got the team up here on the stage, Dave, Armon, Susan, and of course, Navam. So why don't we. We'll start here, then I think we'll work our way to online, but, Attai. Yeah, wait for the microphone, please, then we'll go to these guys up here. Thank you, and thanks for the presentation today. Very helpful, very interesting day. My question is for Armon and perhaps Dave as well. When I talk to users on the floor, it's very common to hear many of them using still the open source version and feeling very good about what they're doing without needing necessarily to open up the wallet and pay for this stuff. So my question is, with the announcements today and perhaps in the way that we need to think about the announcements of the near future or in the future in general, in what way what you're introducing here now and going forward, A, separates the newest licensing version from the forked one that you did a couple of months back, number one. But also, how much of what you're introducing is now exclusive in paid versions- Right. —versus open source versions? 'Cause I think that's where the real big pull... Clearly, you have a massive base of practitioners out there. Mm-hmm. But they're enjoying a lot of free stuff, and at what point does the party end? To a certain degree, at least. Well, the party shouldn't end, but there's a VIP section, right? So we want the party to keep going. You know, I think what you saw hopefully was the theme, if I look across the portfolio, is as we're adding more innovation, it's sort of a split of some of the stuff is going enterprise only, some of it is actually going cloud only, and some of it, it's like there will be a free tier, but then it sort of there's an automatic conversion, right? So good examples across the board, right? If I think about Vault, for example, the Secrets Sync capability we announced, it's available in free tier in cloud, and it's only available in our enterprise self-managed. So if you want Secrets Sync, for example, there is no open source version of it. You either have to go to cloud, and you get your first 25 secrets for free, and then beyond that is part of it. But the Secrets sync is included as part of those paid tiers, or you're on Vault Enterprise and are self-managed. So that becomes kind of a perfect example of as we think about that approach with things like Vault, the direction we're going. If I use Terraform as an example, Stacks is a perfect example of this. So the core of being able to define a stack and have those sort of the layouts in multiple environments, great, you can use Terraform Community to define it. But if you want to do the orchestration and say, "Hey, I want to do a multi-region deployment, a multi-component deployment," you need to be using Terraform Cloud or Terraform Enterprise as the back end to power that, right? So that's kind of the direction of, of all these things and where it's going, is it's not sort of the party's not ending, but how do we give those paths on to say, "Okay, great, you want to taste it? There's a free tier in cloud. You can do it that way, or if you want to stay self-managed, fine," but that's an enterprise-only capability in the self-managed world, right? And so that's how we're creating the right pathways, where people can use the capability and feel it, right? Because I think that's where the practitioners really become a powerful bottom-up motion, is that they can sign up for a free tier, try it out, and be like, "Hey, I tried this Secrets Sync thing to GitHub. Looks great. I want to use it in my enterprise." Okay, great. Either move to, you know, full-blown cloud version or upgrade to Vault Enterprise, and now you can get that same capability. So that's kind of the direction, and you can see even with Consul, that HCP Consul Central we announced, that is only a cloud capability. There's a basic set of features that are there for a limited scale. That's part of the free tier. If you want to unlock the full set of capability, you can use HCP Consul Central with an open source Consul, you can self-manage it, but those set of capabilities are only available if you're paying for HCP Consul Central, right, beyond a certain scale point. So that's kind of the direction where cloud will be a free tier, and then enterprise versions, often you'll only maybe get a taster of it, and then you have to move in self-managed to the enterprise version of it. So that's kind of the logic of where we're going with this stuff. And with other pieces of it, we've shifted entirely to only HCP. So with Waypoint, for example, it used to be both an open source version, as well as a self-managed version, as well as an HCP version. As part of this reset into toward this vision of the internal developer platform, it's only delivered as an HCP service. So it's on- Hey. So there's a free tier again, but then you graduate out into, right? You can come and say, "Hey, great, I do a free first few applications. I get a sense of this thing. I want to apply it at scale. Now I'm in a paid tier," right? That's kind of the core philosophy of where this stuff's going. Just to reinforce, this is a community, a practitioner conference predominantly, so that's where you'll see it. But yeah. Okay. Mark? Oh, thank you. Mark Murphy, JP Morgan. Wondering if you might have any comment on the macro demand environment. Navam, you had given us kind of the thumbs up on the, you know, higher trending on the 100,000 customer adds. I think in the back of all of our minds, you know, there's a little bit of a debate raging right now on whether the hyperscalers themselves are kind of getting a little closer to the end of this elevated optimization, you know, wave. You know, there are some hopes that AWS growth is going to stabilize, you know, around 12% and then pick up. You know, that's so that's a usage model. You're more of an entitlement model. Right. Do you have any inklings on, you know, what the possibility of that might be? And then if we begin to see that in those models, should we be thinking, you know, that there will sort of be a delay, and it'll waterfall its way over, you know, into your entitlement-based model? So could we be sort of watching for what's going to happen in the very immediate, you know, near term here and thinking that this might, you know, foreshadow what is just, you know, a couple quarters down the road for HashiCorp? Do you want me to start or? Yeah, no, I can just make the point. I... That logic feels reasonable to me as a proxy for software spend in general, not HashiCorp specifically. I think that, you know, the hyperscaler spend is so large that it's probably a good proxy for what's happening in IT. You know, they've gone through a consumption cycle, optimization cycle. You know, those of us on entitlement models, yeah, it takes a few more quarters for that to work its way through. It's not a reason—it's a reasonable thesis, I would argue, but that's how I think about it. I don't think I have a different idea than you. It seems like not an unreasonable thesis, that it might maybe a few quarters later, you would see it across the software landscape. Yeah, I think you hit the key point, which is the entitlement model versus the usage model. The advantage of the usage model or the disadvantage of the usage model is any trough in software spending is immediately apparent, and then any uptick on that is immediately apparent as well. That is certainly not the case for us, which is... we deal in more annual cycles of annual budgets being consumed and IT spending on an annual basis as they think about entitlements, right? That's how software is consumed on our side. You know, we're reading the same surveys that you are, and all the early surveys seem to say that there's a stabilization of sort of the downtick and the optimization. So we're hopeful that the next, you know, the next cycle ends up being a more positive cycle. So we, we would expect that to kind of work its way into demand, and then we'll see the uptick in bookings and then RPO and revenue in that order. So yeah, we're optimistic. I'd say that we're, we're waiting. We're, we're gonna execute the next two quarters and, and take a good look at how Q1's trending, and we'll, we'll give you an update there as well. Let's go to Kash, and we'll get a mic in the back. Kash? Thank you, Alex. Kash Rangan from Goldman Sachs. I actually have a question for the newest executive on the team, Susan. Good to see you after a long time. You too, Kash. I can't think of many executives like you that have been at an application software company, security, infrastructure. What is your plan to... If there is a need to retool the sales organization or approach a different sales methodology, clearly, you've been there, done it. This company could be a multiple of its size. What are the patterns that you've seen from other companies that you could apply, or what is so unique to Hashi that you could work on and make it truly the company deserves to be in a few years from now? Sure. Thanks for that, Kash. So as I said, it's really about the simplification, and, you know, I'd love to take credit for the model, but like I said, the team had started working on this before I got here, so our CMO marketing's marketing team. And so I started looking at this with them a couple of months ago in terms of the maturity models that we have, as well as on the technical field organization side, the HashiCorp Validated Designs. And I think really it just comes down to this prescriptive approach, and if I had to tie it back to you know, the patterns, Salesforce, as you know, we got you know, to the point where we had so many products, even in the you know, relatively quickly. It was really interesting because you went from people who know how to sell Sales Cloud, because, of course, they used it every day, and then they tried to sell things they had no idea. You know, so whether it be the platform, which was more tactical or Service Cloud. So I would say that the repeatability in selling is absolutely the key to it, and the way... Aside from these, you know, these very prescriptive maturity models that we have now, that we see our customers nodding their heads on, "Yes, that makes sense to us." So lining up around that, but lining up not just from a how we sell, but that's how our services offerings are gonna be sold as well, is to align with each of those phases. And then that's also the IP we're giving to our partner organization, so the SIs, so that they can help that. So it's all about that repeatability in my mind. And, you know, it'll take some time to flow through for sure, but I feel good about the level of kind of testing that's been done with it, before I arrived, so I'm very anxious to, to get it rolled out en masse. Go to Mike, then we'll go to Jason afterwards. So go to this side next, Jess. Hey, hey, guys, everybody. Thanks very much. Really a pleasure to be here. Armon, for you, maybe we could talk through the licensing question and why the decision at this point to move to BSL from MPL. Obviously, you've had the reaction, if you will, from the industry with the, you know, culinarily named OpenTofu. You know, I'm interested, the Linux Foundation is in there, and some fairly reputable people are involved in that. Why does that make sense at this point, and why are you not concerned about what it might be doing to your ecosystem? Sure. Yeah, it's a great question. I think, you know, almost helpful to take a step back and understand sort of the motivation, and we can talk about where we think this is all gonna go. If I sort of frame it, you know, I think what we saw emerge over the last... Actually, you know, taking an even further step back, we've used MPL, as you said, for 10+ years, right? You know, the MPL, if you're not sort of deeply familiar with it, is effectively totally unencumbered. You can do whatever you want with MPL, right? The challenge is we've spent 10 years creating a large market around infrastructure as code, secret management, network automation, and effectively with MPL, there's no barrier to entry. Anyone can come in, take Vault, put a sticker over it. It's my cool Vault. Now you go sell it for $0.10 on the dollar, right? There's effectively no barrier to do that. I think what we saw over the last few years was the emergence of a set of clone vendors that did exactly that, right? Where they would literally go in their pitch to, to HashiCorp customers, they'd find our user list or whatever it is. "Whatever your HashiCorp bill is, we'll sell you the same thing for $0.10 on the dollar. Like, like, just send us whatever your HashiCorp quote is, and we'll, we'll send a quote back." We saw this sort of behavior, obviously, with small kind of customers, you know, more of the commercial s- you know, smaller, price-sensitive type folks rather than large enterprise. But you can see that sort of pattern of these sort of clone vendors basically eroding pricing power by going in and kind of doing that behavior, right? So you sort of look at it and say, "Okay, well, fundamentally, as a company, you only have a few options, right?" Option one is you say, we ignore that, and we sort of allow them to continue and sort of be ankle biters in our community, and over time, could erode our pricing power. Option two, you say, I'm gonna stop putting IP in the community. I'm gonna only put my IP in the enterprise edition, right? And you can, you know, you can imagine if we went down that path, you can't do it for very long before your community users get relatively upset, right? Option three is you say, "Okay, well, I'm gonna go from a totally unencumbered license to a slightly encumbered license that says, 'You can't do that.'" Right? That felt like the most logical path to us when we looked at our peers like, you know, Mongo and Confluent and everybody else, who effectively, they've all put a slight level of commercial control on their license that says, "Okay, you can't take, you know, Mongo and sell it against me," right? You can't take, you know, you know, in our case, a Vault and sell it against me or Terraform and sell it against me. Effectively, you can do everything else, right? If you're using it for internal purposes in an organization, great, it's unencumbered. You can do that. If you wanna use Terraform as part of your SaaS service to build a Vault competitor, great, you can do that. What you can't use is Vault to build a Vault competitor, right? You can't use Terraform to build a Terraform competitor. So it's actually a relatively narrow restriction. I think the universal feedback from our customers has been, they've shrugged it off because they're like, "Great, you know, no real impact." I think same with most of our user community, you know, no real impact to what they're actually doing with it. And so it's very targeted to basically these, you know, kind of clone vendors to say, "Hey, that's not a behavior we want to enable. It's not really in the spirit of sort of open source, and over time, it would force us into not putting this IP and innovating in the open," right? Which is what we want to continue to do. That drives sort of a bottom-up adoption motion for us, right? So that was sort of the decision-making on it. Now, I think in terms of the impact, we knew that there would be a fork because you have a set of impacted vendors that we just put, you know, frankly, we closed the door on their business model, right? Their business model was, HashiCorp does all of my R&D, HashiCorp does all of my marketing. They throw a conference every year and educate everybody about infrastructure as code, and then we come, and we, you know, put flyers at the front door, right? And so we said, "Okay, that business model is over," right? And so they really only have two options. One is close the door on their own business, or option two is sort of create a fork and create a whole bunch of noise about it, right? And so sort of inevitably, that was the option they took. We didn't think it would be so culinarily inspired. But, you know, the reason I don't honestly lose a lot of sleep over it is, you know, if you go through the list of people involved with it, A, it's, you know, four, five, six vendors that are all direct competitors. They're ones impacted by this, right? None of them, you know, as much as their messaging is, "Hey, we altruistically care about the open source community," you know, it doesn't appear to be true. They all have a very self-serving interest in this. But more importantly, yeah, there's a reason the five of them care about OpenTofu, but why does the rest of the ecosystem care? If I'm a HashiCorp Terraform user, why do I care? And the answer is, you don't, because it's not impacting you. And all of the innovation that you're now seeing, things like Stack is a great example, that's only going to go to the BSL version of HashiCorp Terraform, and in fact, we already have, you know, patent pending on it, right? So that's a capability that's never going to come to Tofu. So if you're a HashiCorp Terraform user, you're going to look at that and say, "Great, you know, license doesn't impact me. I can continue to use the stuff. HashiCorp is continuing to innovate on it." Unless I care to go to one of these five vendors that, frankly, are all Series A, B companies that won't be here in 12 months, you know, why are you going to bother, right? So I don't want to be overly flippant about it, but I'm not losing a lot of sleep. Okay. Why don't we get the mic over to Jason, and Jesse, if we could add 10 minutes to the clock, that'd be great. And then, go to Sanjit and Brad afterwards. Yeah. Great. Thanks, Alex. Good to see everybody. Jason Ader with William Blair. I wanted to just ask you for a quick postmortem on what happened in Q1, and what lessons have you learned from that experience that you hope to take in the future so, you know, we won't have that type of missed expectations again? I mean, I know macro is out there, but now we're nine months after that episode. What have you learned about just the business and the forecasting and whatever else you want to share? Yeah, thanks, Jason. So, I mean, rewinding the clock to Q1 and the beginning of Q1, really, the world... We clearly knew there was a change happening in the market, but the front end of what we were seeing, pipeline creation, the actual pipeline related to the next quarter that we expect to close, all were fairly consistent with what we would normally see in a Q1 and we would normally see in a quarter, right? What happened that we didn't expect was sort of the severe reaction that finance and procurement had for any contracts that were over a certain threshold, regardless of the flavor of what it was in terms of the product. It wasn't, "Hey, we're stopping Terraform. Hey, we're stopping Vault." It was more, "If you're above this, this height, we're gonna stop you. We're gonna have a lot more questions and a lot more scrutiny on whether you are going to spend it now or spend it later," right? So what we saw in Q1 was a lot of those discussions, way more discussions than normal. And Q1 was unusual in the sense that we didn't see any large contract act or, or very few large contract activity happen, right? So that was the learning of how the, the behavior of buyers were sort of evolving in this new cycle of spend, of, of optimizing every dollar, doing more with less. And the reaction we had was then to apply that learning to the rest of the quarters, which is what we did in terms of thinking about how the, how the large contract activity would, would occur in Q2, three, and four, and, and applying that to, to our forward guidance. Right now, Q2, I would argue, was a better quarter than Q1. I'd say that the environment certainly did not get worse than what we saw in Q1. So it's roughly the cycle we're in is this annual budget cycle, and the behavior of the buyers have been consistent in Q1 and Q2. We don't think that behavior is going to change in Q3 and Q4 either. So we're in this budget cycle, we're working through these near-term optimizations that customers are doing, but I think the big thing we want to reemphasize is that the conversations that the customers are having are not about losing to a competitor or canceling a cloud program or canceling a digital... a modernization program. So those things are still occurring. It's just the speed of which is different. There's an elongation happening, and we saw that acutely in Q1. I don't know if there's anything you want to add. Yeah, I'll just say exactly right. I think it's an aspect of deferral, right? That's what caught us by surprise. It's generally, you know, we sell significant things to people, and there are very professional procurement departments on the other side of that, and, you know, they drag things out, and it's difficult to predict when those close. But they don't go away. I think that's the key thing for rain or shine. But it does make... It has made it more difficult to forecast, I'll be totally honest. We're going to go to Sanjit, then we'll go to Brad. Thank you for taking the questions, Sanjit Singh, Morgan Stanley. When I look at Armon's keynote this year, a couple things stood out to me. The add-on capabilities associated with both Vault and Terraform, that seems to be new to me. I haven't seen Nomad get as much love versus, you know, prior conferences. Consul got some nice airtime. And so I guess the question for the team is, like, are you signaling to us that we should start to think about consumption? I mean, Vault's been doing fantastic. I don't think anyone has any issues about monetization with Vault. But we think about maybe improved monetization with Terraform. Should we start thinking about Consul coming online at some point, Nomad, Boundary, Waypoint? I was wondering if you could just sort of walk us through the portfolio and sort of stack rank how we think about monetization, and not necessarily for Q3 or Q4, but going into next year and beyond? Sure. Yeah, happy to. Yeah, I mean, I think obviously Terraform and Vault remain kind of the core products. They're, they're the lion's share and the driver of this stuff. I think the bigger philosophical shift for us within product group is really to say, you know, how do we really streamline our products? And you can kind of see this in the way we demoed and talked about it, where there's a logical pull-through behind those two, right? If those two are the tip of the spear, then what's the logical pull behind of next product, right? And so you can kind of see that when we frame it around infrastructure and Security Lifecycle. Each of them has one logical tip of the spear, and then the rest of the portfolios just sort of sit behind that, right? So that's kinda how we're thinking about evolving, where before, maybe you saw us talk about a four-layer stack, where Consul and Nomad almost have their own insertion points, right? How do we sort of increasingly say, "Actually, do those make sense as a land product? No, that's gonna complicate our sales motion. Let's just land Terraform and Vault. What's the extension motion, and is there a set of feature capabilities that more tightly aligns them to pull it through," right? Like, I think a great example of it is where we've realigned HCP Waypoint, where you can clearly see it's an add-on to Terraform, basically, right? You define your patterns as a platform team with Terraform. The add-on now becomes great. Well, Waypoint, isn't that my abstraction layer, where I go from 1,000 people in platform team to 10,000 developers? Exactly. That's exactly how we'll message it. And so it becomes this logical pull-through sell to the platform team. They say: How do I enable my next x thousand developers? Great, you layer Waypoint on top. Now it's an accelerant, both of Terraform, but it's also its, its own net new product, right? Vault, you can see the exact same thing. Great, I might land with Vault, but Radar becomes both an accelerant to Vault, as well as its own net new product that your sellers selling in. So if I sort of stack rank them, right behind, I, I would say, you know, Terraform and Vault, obviously one and two. Number three, I might actually put Boundary, and I think the reason for that would be it's a really tight pull-through behind Vault. You can kinda see in some of the quotes we're seeing. People see the logical one plus one, which is great. If I have Vault doing my dynamic secrets, Boundary is now doing the human access side of it. The nice thing about Boundary is it sells to an existing product market where people understand it, right? There's a PAM team in every company you talk to or an identity team. They have an existing spend. There's a budget line. So it's a really clear motion of who do you sell to and what budget are you going after. Consul, I think, is more complicated because, by definition, people don't think about service networking in quite the same way in a traditional data center world. So I think as budgets get sort of aggregated into a cloud platform team, they become your buying center, but it requires a little bit more organizational change in a way that Boundary doesn't. Boundary, there's just an IAM team, and they own it, right? So I'd stack rank Boundary probably first, then Consul second. Nomad, I'd still put third, if only because I think it's a, you know, it's a—there's some interesting upcoming use cases like AI, but I think the markets are just much bigger around when you think about the applicability of Boundary, the applicability of Consul. I just wanna tie it also to what Susan said, because I think what you see us, it, it sort of acknowledging is maybe two things. One is we're engaging the early majority of the market, not, not the early adopters, right? That requires us to simplify it the way we engage. Point number two is this notion of Infrastructure Lifecycle, Security Lifecycle is very linear in the path. Like I said, provisioning process is Terraform, Packer. Like, it's very, it's, it's very, very consistent. That's what we're trying to simplify the message for our field organization, too, because people actually want the prescription, you know, as opposed to like, you know, which of these independent things are we gonna, we're gonna let people adopt, because the skills required to do so is higher than perhaps the early majority has. Okay. Brad here, then we're gonna do a couple of online questions, then we'll get back in the back here. Great. Thanks so much. Brad Sills from Bank of America. We've seen those impressive slides where customers start small, $800,000, then they get to $1.7 million, then they get to $3.4 million, and they have multiple examples of that. Are there any milestones or triggers that you've identified, Susan, that occur along the way, such that customers make those choices to go bigger? And how are you thinking about moving customers along that path, as you've... It's only been a few months, I know, but what are some of the things you've identified? I might be able to talk to it. Why don't you start? Yeah, I can sort of speak to, just 'cause I think I've sort of had a relationship with many of those customers, and so kind of see the, see that journey. You know, I think it's, it's very, very consistent. You know, what happens is it tends to be single product, single use case, single BU is the start point, and that's great. That's the $250,000 buy. And then from there, it's like, "Hey," another BU is like, "Hey, what's that team doing on secret management? That looks cool. Can we talk to you guys about Vault, too?" And now you're having a conversation with two, three other BUs. And so it goes from, "Great, I had one Vault, now I have four Vaults," 'cause each of these BUs is now doing it, and so you see one level of staircase. And then from there, now I'm in a position of trust. I start having a conversation around: Hey, what are you guys doing with provisioning around Terraform or, you know, whatever, network automation with Consul? That becomes the second layer of conversation. At some point, though, these organizations realize, "Hey, it doesn't make sense. Every business unit is reinventing the wheel to cloud. That doesn't make sense. It doesn't scale for us. How do we have a more central, platform-driven approach?" It's the construction of that platform team, which now says: Okay, five different app teams shouldn't figure out secret management. It doesn't make any sense. I'm gonna pull it in and define a standard. So we might have sold to two or three of them, but once it gets pulled in, now it's like: Okay, well, I'm buying at scale. I'm buying for the whole group.... rather than each BU at a time, that becomes that step up, where now it's a platform level, and you're a strategic trusted vendor. It's saying: You guys are my secret management strategy. You guys are my provisioning strategy, right? In the automotive example, you guys are my networking strategy. So that becomes that kind of a shift. And that's why I think, to Susan's point, like, that, that land expand becomes super critical because, like, you just had to land in the one BU to start having the conversation, but you know that every BU is solving the same problem. Right? And so if you can win the trust, and they're like: Great, we know you got through our security, and compliance, and legal review, Vault's the easy path. Great, I'm just gonna pick Vault 2, because business units 2, 3, and 4 don't want to have to fight that battle with a different product, right? They're like: Great, if Vault already is approved and blessed, just go do it. You know what I mean? And so that becomes exactly the story, and that was the story with these guys. You won the core use case around cloud, then they say: Great, well, why can't this pattern apply to my private data center? It can. Okay, great. Why can't this pattern work to my manufacturing? It can. Okay, great. So you went from one cloud region to multiple cloud regions, to private data center, to 80 manufacturing sites, and that's what starts to drive that. I think there's probably a time horizon overlay to that. I think, you know, if you ask our reps, they'll say it's year three. All right, we're gonna go online, then we'll go back into the room. So Ron? This one's directed at no one specific. With the recent breach headlines at companies like MGM, Cedars, Clorox, we're hearing more positive commentary on demand for privileged account management and zero trust. How do you see that playing through to Vault and Boundary? Are you seeing these events driving incremental demand? Yeah, I mean, I think in general, what we see is, you know, this is the disconnect between what I'd say, what we see a top of funnel versus just the procurement environment, right? Top of funnel, I don't think we've seen any diminished demand. In fact, you know, on cyber, to your point, it's probably accelerated because I think these risks are still very top of mind, and I think the need for automation is very top of mind on the infrastructure side. So I think the interest we're seeing is super, super high. That's why we're sort of optimistic, and I'd stack rank Boundary at the top behind the core products. I think there's a ton of opportunity there. And so I do think the demand is certainly there. I think the challenge is everyone's operating with either, you know, flat or down budgets for the year, right? So that's what's sort of driving... You know, the deal cycle is different. You know, the bottom of the funnel is different from the top of funnel. Top of funnel, I think, yeah, demand, demand signals are all strong. Okay. Miller, did you have a question? Yeah, we'll get over here, and then we'll have a question over here. I'll go to Derek, then James. All right, thanks. Miller Jump, Truist Securities. You know, some of the features that you announced today were kind of around optimization tools. You had the locality tool. You also had the ephemeral workloads. I guess, you know, as you think about those investments, I'm just curious, are you seeing optimization? Like, is this indicating that you're kind of seeing it as a new normal, or, you know, is it still like a periodic phase that companies will work through? I guess, how are you looking at that? No, I mean, the way I think about it is every cloud program fundamentally goes through three phases, right? Phase one for every group is: How do I enable my developers to consume cloud, right? So my first challenge, if I'm sort of a platform team, is enablement. Challenge two becomes, okay, I've enabled people, now I've created a mess. So how do I sort of put the right governance and controls in place, right? So you go from, "Hey, I want to let people stand up and create a Terraform pipeline. They can go out and do whatever they want," to, "Oh, shit, they've done whatever they wanted. Now I need to put the right guardrails and sandbox them in." So there's a sort of a risk management posture. And then phase three is, okay, I made it safe for them to do cloud at scale. Now they've done cloud at scale, and I have to pay for it. Now there's a cost optimization part of it, right? I don't think I think about... It's not like an acute thing, but it's an ongoing forever thing, right? Like, you know, if I'm, you know, have a six-figure, seven-figure, eight-figure, nine-figure cloud spend, right, I'm gonna always be thinking about it. I think that's what you see in large, mature organizations, usually have one or two FinOps people dedicated to, to sort of infrastructure optimization. When we think about what's the commercial value prop, we think about it across those buckets. It's like, what's a set of capabilities that's enabling people to do things at faster scale? Things like what we announced with HCP Waypoint falls in the enablement bucket, right? I'm enabling developers to consume faster. Some of the things we announced, you know, around Run Tasks and the policy sits in that risk management category. Great, how do I actually manage my risk around images, deployments, Stacks? There's a risk management set of concerns, and that's part of the commercial value prop. And the third bucket is how do I optimize cost at scale? And so there's a set of value prop there around traffic routing optimization, ephemeral workspaces, things like that. So those three buckets are kind of where we invest from an R&D perspective. I don't think about it as like, specific to this year or this optimization cycle. Those are just the vectors among, you know, which are our commercial value prop sets. Thank you. Derek? Thanks. Derek Wood at TD Cowen. Susan, at your past companies, channel has been pretty important. I'm just curious what, you know, the status of the channel engagement is today and what new initiatives you could drive. You mentioned that, you know, you're trying to kind of push to customers, not that you could do this, that you should do this, and I'm just wondering how the partner channel could kind of help you with that message. Yeah. So, a couple of things. So when I think about... I think about the entire ecosystem collectively. And, on the partner channel, certainly we want to use them to extend our reach, and we do have engagement with the partner channel. Now, that said, when we think about the simplification we're doing for our own employees, think about the fact that that's even ten times harder when they're not your employees, right? So there's a lot of footwork that we're gonna need to do there. But my number one focus is I'm getting a very, very deep bench on the SI side. So whether it be boutique SIs, global SIs, but boutique generally go first. That's what happens, right? And then the global SIs buy them. That's generally the pattern. It's, it... They don't need to be- Right. They don't need to be early in, they just need to be able to buy them eventually. And so from that perspective, we focused a lot on that in the partner section, today, because all of this IP that we're creating internally to be prescriptive, we want to share very openly with the SI partners and have them, you know, build their practices around it, so. That's a big part of the focus. Okay. We're gonna do Jim, then Pat, and we'll go back online. Thanks, Alex. Thanks, everyone. Jim Fish with Piper. Armon, maybe for you, can you go through the differences on Stacks for what creates that complexity to cause you to then consider that commercial version specifically, as you alluded to earlier? And then, Susan, just building off of actually Derek's question right there, you mentioned moving towards, you know, what customers should do. How do you actually change that mentality of your team underneath to think about it that way as opposed to that evangelical sale of what they could do? And are you thinking about any, like, new packaging for the next year to encourage that kind of cross-platform adoption? Sure. I'll tackle the first part, and then let Susan tackle the second, third, and fourth part. I think on the first part, sort of like, what's the delineation, I think, was sort of the question of how do we think about maybe Stacks community versus commercial component, if I... I think if I parse that. The way I think about it is the challenge we see within sort of the more complex deployments is there's typically a level of feedback required and policy enforcement required. A great example of this is most enterprises would say, "You can't deploy to my production environment until you've deployed to staging. You can't deploy to staging until you've been to my test environment." There's a logical progression. You're forcing developers to say, "Go to test first, make sure it works, go to staging, validate it, then you can go to production." And then in most production environments, you sort of gate it into a phased rollout. So you might say, "Okay, you can go to my Canada region first, then you go to Europe, then you go to North America." So there's a sequencing. So a lot of what the commercial product will do is enable you to basically enforce those controls and manage that sequencing to say, "Okay, great, deploy the stack. Okay, now I want to enforce that it's going through that logical sequence, and I'm putting the right gates and policy," and you're gonna have different approvers. So my developer might be able to approve out going to staging, but I have an ops person actually approve it going out into production environments. So things like that, that becomes the kind of workflow where today, you know, you basically have to kind of build on top of Terraform Cloud and use our, you know, build your own kind of some glue on top of our existing workspace model to be able to do that, versus Stacks will give you a first-class workflow for that. But that will only be delivered, that sort of core workflow orchestration engine will be part of the commercial product, right? Simplistic things of, great, I have a two-layer stack, and I'm deploying it in one shot to prod. Great, you can that, you know, that basic level stuff will be available. The more complex flows, which will be what our kind of commercial customers require, that'll be in the commercial product. Okay. And to answer the question about how do you change it from evangelical sale into the should and, and getting your reps to talk that way and then getting your customers to believe that, I think the good news is that there's an awful lot of proof points, right? So we have, whether it be the speed, cost, risk, data, we have the customer stories. And so as we talk about, it's really, really important to understand this early majority thing because these are the people who know they want to do it, but they also know they don't know how to do it. So they're leaning hard on us to bring the how. So from that perspective, I would just lean on, we have so many proof points that this is exactly the way it plays out for those customers who, you know, who have... were the early adopters and have been incredibly successful. So I feel good about that. Okay. All right, Pat, and then we'll go online question, and kind of finish up here in the next five minutes. Great. Thank you. Pat Walravens from JMP. So I know it's a little unfair, but any thoughts would be appreciated. There's three weeks left to go in the quarter. How's business? They're telling the bomb assassin. Yeah, look, we follow typical enterprise cycles when we deal with our customers, and you know, the quarters tend to be very tail-end weighted. So, you know, we provided guidance on how we think the quarter is gonna go, and we're gonna go execute on it. This month's a big month, and we're feeling optimistic about our execution ability. Was there anything else there, Pat? That was it? Straight down the middle. All right. Ron? Question for Navam. Given the platform selling with multimodal form factors, i.e., some self-managed, some cloud, what implications for rev rec should we consider? Yeah, I mean, I think that just to parse out the question, the self-managed side has an upfront revenue recognition component for multiyear deals, and cloud is purely ratable. But even in those self-managed environments, you know, the upfront component is comparatively smaller. So the maximum amount... The amount of upfront revenue we tend to have in any given quarter is somewhere around that 10% mark, give or take, depending on seasonality and depending on whether it's sort of the fourth quarter or the first quarter. It ends up being bouncing around that 10% range. So it doesn't make or break a quarter, per se. It certainly, you know, contributes to the quarterly revenue, but it's been relatively consistent in how much upfront revenue there is versus ratable revenue. The net is, though, that regardless of what flavor it is, it is very predictable in terms of the stream of revenue we get in the tail end. So it is a more ratable than not company, from a revenue perspective. Obviously, as we get more cloud, you know, you're gonna get more and more of that, that ratable revenue base. Okay, we've got a couple more minutes. Any last questions? Darren, then we'll go to Jason. Darren? Hey, guys. I know half of you can't see me back here. But, I'm Darren, with PRIMECAP. I kinda wanna ask just a question that touches on several of the things you've talked about, but maybe we could kind of pull it all together, right? Specifically, I mean, Dave, you talked about, you know, in your presentation here, how you're finally kinda starting to see some of these big customers being willing to consume managed infrastructure, right? Rather than only doing self-managed. And I’d love to hear, like, how we should think kinda holistically about how a customer that moves to primarily using your SaaS products versus self-managed, how that looks different to you from a business standpoint, right? And that could be, you know, financially in terms of the rev rec, or the margin profile. It could be, you know, whether they are more kind of inclined to adopt the suite, you know, offering that we've been talking about here, or any other aspects. But how should we be thinking about the evolution of those customers as they become, you know, primarily SaaS rather than just doing things on their own? Yeah, I think of it in two categories. I think clearly it is more cost-efficient for us to manage. Like, you know, we... Our support organization bears a heavy load for companies that run nine versions behind of our product and then call us with issues. So I think the margin profile is one, it's more of like we get much more efficiency of running it for them, for them, largely on the support side. Number two... And that's very clear. So it is our very strong preference to manage it for people. We're just cognizant, and I, I always make this point, like, when you think about who else big companies in the world trust to run their infrastructure, infrastructure, it's Amazon, Azure, Google, et cetera. It's nobody else. Like, we're in that category of one almost, because there's no other infrastructure vendor that does it, so the bar is super high. Number one, it saves us on the support side, in particular. The real reason that it's interesting to us is because the time to success is just massively accelerated. The next use case along, the next product along, we know happens faster. I think that Singapore Press Holdings is illustrative of how it works. That's not a huge organization, but I've watched that happen, and it blew my mind how fast that happened because the friction of onboarding is just not there. That's really what's interesting to us. Financially, next use case, next product. Basically, the net NDE naturally happens faster, and they get on the value realization cycle much, much faster without as much energy from us. So, you know, we would like that model. There, there's a market reality to it, so. Yeah, I just wanted to follow up on the conversations on monetization. And clearly, there's a difference between Terraform and Vault in terms of monetization. I thought maybe it would be helpful to the audience to just explain why Vault seems to monetize better. And then secondly, I think it was a year ago, a year and a half ago, you know, there was this killer feature, drift detection. We haven't heard much about that, and I'm just kinda curious, like, why should we believe that the next new feature that you've offered here is gonna not be like drift detection? What is it about the new things that you're bringing to the table that could actually drive greater conversion, greater monetization? Sure. Yeah, you want me to take it? Yeah. Yeah, I think the difference between Vault is, you know, Vault is obviously a runtime product, so it sits in a more critical sort of a path. Every application is wired into it. It talks to it. If it's offline, typically takes a data center with it. So I think there's just a different level of sensitivity when you think about, okay, given that criticality, there's a set of Vault Enterprise features around high availability, around disaster recovery, around multi-data center deployments, that if you're operating in a commercial environment, you're like: Okay, I kind of... You know, not running without that is uncomfortable, right? Because you're saying, if I lose this one Vault cluster, I'm losing my whole data center and potentially multiple data centers. So I think there's just a very clear and obvious reason where you say, "Okay, great, for all of those set of capabilities, HA, DR, multi-data center, et cetera, you're gonna want to move to enterprise in addition to a support relationship, because it's sort of a, a Tier One runtime system," right? So I think it, it's the properties of Vault by nature of both being a security product and a runtime product that, that drives some of that. That I think just makes it a lot clearer, I think, for customers to understand. I think on the Terraform side, I think features like drift detection, you know, we didn't talk about it because it's sort of not a new feature, right? So we're not... Typically, we're talking about new capabilities rather than sort of rehashing. But, I think from a customer conversation perspective, that is a key part of the day two, day three value story, right? So I think the story we articulate is, what the community products solve is really a day one problem. Great, you want to deploy your app and just use Terraform for that? Great, that's a day one thing. How you actually build and maintain it, day two, day three, day four, and beyond, how are you making sure it's secure? How are you making sure it's compliant? How are you making sure it's patched? That's the lifecycle management piece of it, right? So when we talk about going just from the provisioning to the full life cycle, that's where a bunch of the commercial capability focuses, including drift detection. So a key part of drift detection is: Okay, well, great, you have 5,000 things running in cloud. How do you know which of them are out of date, right? Or which of them have a security policy that's incorrectly applied to them, right? Those kind of things. Drift detection plays a key role in that, so that's part of the day two value prop. Doesn't quite fit the sort of new features that we would talk about at a keynote, but it fits into sort of the, the pitch when we're talking to customers as to, "Hey, here's why you should think about your full lifecycle management and not just fixate on, 'Hey, did I solve my day one problem?'" Right? And I think that's kind of the, the core difference. I think the, the other piece of it is, it's a education problem. People don't realize the day two problem often. It's easier to just go use community Terraform and go deploy and solve your day one problem. You gotta get to sort of the right leadership who understands, okay, I have a life cycle that I care about day two and beyond, 'cause the app teams often don't care about that. The app team that pulls you in and just uses community, they're like: I deploy my app, I'm at the company for 2 years, I move on. It's the CIO's problem of like, okay, these 500 apps, who's patching them? Who's maintaining them? Who's gonna deal with the curl vulnerability that just got announced that's being disclosed tomorrow, right? So you have all these apps you're gonna need to go patch tomorrow. How do you know which of them has been, has been patched, right? That's your problem operationally. It's not your developer problem. Yeah, it's not one thing. It's a sort of, yeah, it's that suite of sort of life cycle management, right? And Drift Detection is another key piece of that. In addition, you know, Stacks will be another key piece of that, right? So I think it becomes sort of a. It's not one thing, it's a collection of life cycle management. You want to sneak one more question in here? Well, we've got to use the microphone, though. Thank you. Sorry about that. Going back to your comments, Dave, that customers are starting to feel more, pretty much more comfortable moving to the cloud and deploying there. It felt like a lot of the announcements made today, Armon, were kind of stitching in gaps. Mm-hmm. in some of the, right, and making the life cycle now is truly seamless, right? Yeah. There's a lot of kind of gaps and missing features and capabilities have now been filled in. I'm trying to take this next level here. From a bundling standpoint- Mm-hmm. Help me understand how you can wrap this together, not just from a technical standpoint, one product can talk to another and create a full life cycle, but also from a sales motion standpoint, how do you stitch it together as a bundle? Is there an infrastructure life cycle bundle? Mm-hmm. Like, what is this the next logical step? How far are we from that? What's missing? Why, why would that not be available in market here today? Sure. Yeah, I can speak to it at a high level. Yeah. So I think today we have one bundle, which is sort of a Zero Trust security one. So that kind of packages everything that's in that life cycle. So Terraform, I'm sorry, Vault, Boundary, Consul, so as part of that, and then Radar will become another logical piece of that bundle. So there's a sort of a logical security bundle we have today. You know, infrastructure tends to be the Terraform and Packer almost always get purchased right away together just because they're so closely related. Nomad and Consul, still a slightly different, so they don't quite package in kind of the same way, but over time, you can imagine a logical infrastructure bundle that encapsulates all of that. I think, you know, going back to the point on simplicity, long-term, what's clear is we're not gonna want to sell to a customer by having 10 different contracts across 10 different products. We're like, clearly, that's sort of an insane way to do things, right? We're only going to have more products and more modules over time. So even when we talk about Vault, it has multiple modules. You have a base, you have ADP, you have other capabilities. So you don't want to end up with multiple contracts for each product, which becomes crazy. So over time, I think the actual logical correct path is more like the cloud providers. You have a single dollar-based EDP, and then you have a consumption schedule across a portfolio. So I have one contract. I say, "Great, it's $500 a commit." Maybe you consume 75% of that on its Vault, 25% is Terraform, and then great, now you want to start lining up other services. You can do that under a single agreement. I think that's the logical simplification that we need to get to, because otherwise, yeah, over time, you would say 10 different products, multiple SKUs and packages for each, it becomes crazy. It's not sustainable. Okay. Thanks, Ty. All right, we're going to finish there. Thanks, everybody, online and the folks here in the room. Thank you very much. Appreciate it. Thanks for coming. Thank you.