A website has attracted an audience. Then the audience takes it down. For Sebastian Stadil, that small humiliation became a problem worth returning to for years. He dates the episode to 1999, when traffic from Slashdot overwhelmed his shared hosting server. Attention had arrived; the machinery had declined the invitation.
His response eventually became Scalr. The early project helped people manage the infrastructure beneath their applications, the uncelebrated arrangements that determine whether success produces a working service or an error message. Today, Stadil is Scalr’s founder and CEO, and a cofounder of OpenTofu. His work has moved from scaling servers to questions about the control of shared software.
There is a thread connecting those jobs. A developer can do everything expected of them and still depend on a decision made elsewhere: by a hosting provider, an internal operations department, or the owner of an essential tool. Stadil has repeatedly built around that dependency. Along the way, he has also learned that some problems are rather less impressed by automation.
The crash before the company
In his account of Scalr’s beginnings, the initial solution was modest. A community wanted more and was prepared to pay, giving the project a commercial reason to continue. Scalr was released to the community under the GPL in April 2008. The work began around Amazon EC2, before broadening as cloud services developed.
“Because infrastructure is so hard to do right!”
Sebastian Stadil, on leaving his job to build Scalr
Renting computing power did not make the arrangements around it disappear. Machines still had to cooperate. Applications still needed somewhere dependable to send their requests. The attraction of automation was quite practical: fewer things for a person to remember when the system was growing or something had failed. The person behind the product was working on the chores that the promise of cloud computing could make easy to overlook.
His ambition was to make deploying and operating applications simpler. That ambition leaves room for a great deal of work. An application’s first working version and its dependable operation at scale are separated by decisions that rarely appear in the demonstration. The demo has excellent manners. Production tends to be more forthcoming.
- 1999An overloaded shared server
- 2008Scalr’s public GPL release
- 2016An OpenView-led Series A
- 2023OpenTofu’s foundation launch
A room full of people with the same problem
Stadil also founded the Silicon Valley Cloud Computing Group. Its early gatherings took place in Intalio’s small offices, with Stadil greeting attendees at the door. That is a useful detail in a career otherwise populated by platforms and acronyms. Someone had to welcome the people who would exchange the knowledge.
By 2014, he described a group of more than 8,000 members meeting monthly. He was also discussing his work on Google’s Cloud Advisory Board and as a lecturer at Carnegie Mellon. These activities put him in several conversations at once: what developers wanted, what large organizations feared, and what cloud providers needed to hear from people using their products.
He had an accessible explanation for the organizational problem. In an older enterprise workflow, a developer requested a machine through a ticket and could wait six to eight weeks. Cloud computing reduced the wait to minutes. The review that once accompanied the request could disappear with it. Speed had changed; responsibility still needed somewhere to live.
Stadil’s question: how do you preserve oversight when the waiting disappears?
That tension appears in his 2013 QCon talk, Architecting Organizations for the Cloud. The subject included adapting the organization itself to a different way of working. You could buy access to a server much faster than you could settle every argument about who should be allowed to use it.
Even Eurovision needs an operations plan
One of Stadil’s more entertainingly concrete examples came in 2013. Scalr customer grandcentrix was building the backend for the Eurovision Song Contest’s companion mobile app, using Google Compute Engine and Scalr. The audience was uncertain. The infrastructure had to be ready anyway.
Stadil’s account concentrated on load testing, predictable performance, and an architecture that could expand across machines. The musical spectacle was somebody else’s department. His concern was that an application should keep working when people decided to use it together. It was the old shared-server problem with a considerably more elaborate soundtrack.
He also published disk-performance comparisons, paying attention to variation as well as speed. Reliability, in that telling, meant knowing what would happen when demand arrived. A fine result on a quiet test run offered limited comfort if the behavior changed when it mattered. His interest was in the repeatable result, the one an engineer could plan around.
In January 2016, OpenView announced that it had led Scalr’s $7.35 million Series A. The investor described an enterprise need to let developers build across clouds while retaining governance and cost control. Its account named customers including Expedia, Samsung, Accenture, and NASA’s Jet Propulsion Laboratory. The investment was intended to expand the company’s sales presence.
The business had grown around an awkward negotiation. Developers wanted to get on with their work. Central IT had obligations that could not be waved away by enthusiasm. A useful platform had to make cooperation bearable for both. Scalr’s present focus on Terraform and OpenTofu workflows puts that negotiation into the systems teams use to propose and run infrastructure changes.
An experiment that refused to scale
Stadil has also written about applying automation somewhere much less predictable. In 2016, he published a personal essay titled Looking for the One: How I Went on 150 Dates in 4 Months. He had built software to automate parts of online dating, including swiping, messages, and scheduling.
His account recorded considerable activity and a disappointing result. The essay’s subtitle described a failed attempt at engineering love. It is a revealing episode because he wrote about the failure himself. The person who made a business out of helping systems handle more demand had found an arena where increasing the volume did not deliver the outcome he wanted.
It would be easy to turn the episode into a joke about engineers. Stadil had already supplied enough self-examination to make that unnecessary. The more interesting detail is his willingness to publish the gap between a functioning process and a satisfying result. An efficient schedule can still be an efficient schedule of disappointment. People retain the inconvenient privilege of having their own plans.
Who holds the keys to the tool?
In 2023, another form of dependence became central to his public work. HashiCorp changed Terraform’s license from the Mozilla Public License to the Business Source License. Terraform was already part of the infrastructure tooling on which other companies and users depended. A decision about licensing therefore traveled well beyond the company making it.
OpenTofu emerged from the response. Initially called OpenTF, it launched under the Linux Foundation in September 2023, with Stadil named as a core contributor. Scalr joined a coalition that included Gruntwork, Spacelift, env0, and Harness. Companies competing for customers could still share an interest in the availability and governance of the underlying tool.
The distinction matters when considering Stadil’s position. He was a company founder with a commercial stake, participating in a project intended to outlast any one vendor’s preferences. Shared governance gives competitors a place to cooperate on the foundation while continuing to compete on the services built around it. Maintaining that arrangement is work in its own right.
Stadil described openness as having three parts: licensing, community participation, and the development process. His objection was that a permissive license alone did not settle how contributions were welcomed or how decisions were reached. A project could publish its code while leaving consequential choices largely in one organization’s hands.
His early OpenTofu interviews also emphasized compatibility. People needed a practical route from the tool they already used, with room for different teams to move at different speeds. The goal extended beyond making a statement. The replacement had to fit into work already underway, then develop features through a broader community.
“Over time, open source standards tend to win”
Sebastian Stadil, discussing OpenTofu in 2023
The next room is in Salt Lake City
OpenTofu Day first ran alongside KubeCon Europe in Paris in 2024, with Stadil as a co-chair. The event’s practical invitation was to bring experience and questions. Its lighter details included plans for baby and toddler onesies and socks as conference swag. Even infrastructure events can acknowledge that their attendees have lives outside infrastructure.
Away from infrastructure, he enjoys Dungeons & Dragons with friends and spending time with his two boys. The details lend some welcome scale to a public identity built around enterprise systems. Away from work, there are other people at the table, and rather different reasons to keep the evening going.
By October 2026, he was inviting the community to OpenTofu Day in Salt Lake City on November 9. He described a change in the questions: the early discussion about whether and how to migrate had moved toward operating at scale and building platforms. The event’s purpose still included getting maintainers and people running the software into the same room.
That is a fitting place to leave him for now: organizing the next conversation. A shared server once failed to cope with its visitors. Years later, Stadil is still concerned with what happens when people arrive, what they can depend on, and whether they have a say in the arrangements. There is software to build. There is also a door to open.