CloudWright – Build apps in your own cloud

Today we are announcing an open beta for CloudWright , a platform for anyone to build serverless applications in their own cloud which seamlessly combine their internal APIs, databases, and SaaS applications like Airtable or Gmail. CloudWright gives teams:

• A web IDE with autocomplete and live testing
• Painless integrations with services, easy to set up and re-use across scripts
• A zero-setup user interface to run scripts and track progress
• Cloud VPC deployments

Examples of things we’ve built using CloudWright:

• Script to push custom SQL database metrics to Datadog on a schedule
• Templated BigQuery reporting tool , handed off to business users
• Lightweight backend API for use in a Retool web UI
• Customer-specific automated file reformatter

In this post we want to explain what we’ve built and why we think it will empower teams. But if you’d rather jump straight in and start building, you can do it right here .

No-code can mean no-go

There’s been an explosion in the popularity of no-code platforms like Zapier and IFTTT. We use (and love) Zapier in particular, but we’ve seen people hit a wall when using them to build core business applications for a few reasons:

• Data security concerns often prevent these platforms from working with a company’s most important data
• Integrations are rigid and rarely work exactly as needed
• Actions can’t query data needed for custom business logic (like looking up a customer by ID in the middle of a flow)

No-code tools are powerful because they enable everyone to solve a category of problems they aren’t otherwise equipped to solve. However, we believe there’s a large class of problems that can’t be solved without code — we want to solve those problems.

Code-First

We have a couple of predictions about the coming decade:

1. The world will never again be cleanly split between engineers and non-engineers. Most people will learn to code, whether in high school, college, or on the job.
2. Cloud APIs will continue to abstract infrastructure so you can focus on business logic

This will empower everyone at an organization to solve problems with code, and we want to turn that code into reliable applications, by providing a “default correct” set of tools. We want coders to securely handle secrets, failures, and connections to internal APIs and databases without being fluent in cloud infrastructure.

We worked at LiveRamp as it grew from a 30 to 1000 person company, and during that time we built a simple system that could run ad-hoc scripts for our non-engineering teams. Usage exploded, with our Technical Account Managers writing hundreds of scripts to power alerting and custom workflows for their accounts. We wanted to unlock that value for the rest of the world, and so we built CloudWright .

CloudWright

So how does CloudWright solve these problems? We’ve built out a suite of features designed to get anyone on a team writing code as fast as possible.

Web IDE + autocomplete

Setting up a development environment is an enormous barrier to getting started on any coding project. We hate that. CloudWright provides a powerful web editor (powered by Microsoft’s open-source Monaco web editor ), including autocomplete on our integrations:

Live testing

Being able to iterate on scripts as they are being written — even when those scripts are being run against remote resources or databases — is critical. Our dev environment includes a robust “dry run” tool to live-execute code:

Reusable, shared integrations

The biggest barrier to integrating with external services is usually the one-time setup cost — provisioning access credentials and wiring them into your application.

We prioritized making it easy to set up integrations; we wanted our configured integrations to combine the packages, configurations, and secrets needed to connect to a service. And once configured, sharing an integration with the rest of your team needed to be secure and easy.

Automatic User Interface

Last, building an application was only half the usability story — only very tech-savvy teams want to be handed a script and a bash command to run. Usually, the other half of the job is building an interface to hand to end-users, with defined inputs, outputs and monitoring. We wanted this interface to be an out-of-the-box feature:

Deploy to your own cloud VPC

We wanted CloudWright to be a tool for deploying real internal applications, and to us, being a “real application” meant we could do two things:

• Deploy into customer VPC networks, to promise strong security and data stewardship guarantees
• Deploy tools as cloud-native components, not as custom black boxes

In the age of GDPR and CCPA, one common data governance requirement is “Our data can’t leave our cloud” — a challenge when using external tools. To meet this bar, we needed to deploy behind firewalls and into a user’s VPC.

We’ve documented more about our network access story in our docs , but the short story is that we can use a limited-access service user credentials to provision resources in any cloud:

Using this model allows us to give strong governance guarantees — that a user’s code is always executed in their own cloud, the data never leaves their cloud, and they have full control over auditing and credential management.

(we don’t have a fully on-premise version right now. If you want to use CloudWright, but require on-prem, shoot a note to [email protected] , and we’ll let you know when it’s available)

The best way to deploy reliable applications was to have no runtime dependencies on our own control plane. This meant that:

• User code is always deployed as native serverless functions
• Scheduling happens via native event generators (CloudWatch)
• External endpoints happen through an API Gateway
• Secret management always happens in KMS
• Application logs live your infrastructure, not ours

When you deploy a CloudWright application into a VPC, you’re not deploying a magic box — you’re deploying a Lambda with a bit of middleware, and we couldn’t break it if we tried.

Portability First

It was important to us that applications built in CloudWright stayed portable. We wanted to make it easy to build internal Python applications, but without lock-in.

So we built all our integrations on top of open-source Python packages; our preconfigured integrations handle boilerplate like secrets and configuration plumbing, but hand back open-source, documented Python libraries.

If you want to move an application off of CloudWright, the only work you’re doing is work you would have done anyway — handling secrets, initializing integrations, and provisioning infrastructure. To put it tritely: a lot of low-code or no-code solutions keep you hooked on special sauce — we wanted our solution to serve ketchup.

What are we asking for?

We have a free public version , and we want you to try it.

We know this is an ambitious project, but the goal — turning everyone into builders — is one we believe in. We’d love for you to try us out, tell us what we did right, and complain about what we did wrong (feel free to leave a comment here or send us an email ).

We’re looking forward to what comes next.