SaladCloud recipes are designed to remove friction for teams that want to ship quickly on distributed infrastructure. Each recipe bundles best-practice configurations, tested defaults, and concrete operational guidance so that operators can stay focused on business logic instead of infrastructure plumbing.
In the Salad ecosystem, recipes are not just examples or copy-paste snippets. They are deployment templates that encode how to run real workloads on a large, distributed GPU network with minimal work.
What Makes Recipes Work
At their core, SaladCloud recipes are pre-configured deployment templates for Container Groups. They come with sensible default parameters and configuration values that you can either take as-is or adapt to your own workloads. SaladCloud Documentation
Instead of digging through docs, trying to remember which environment variables matter and which probes you should configure, you start from a template that already reflects what has been learned from running that workload type on SaladCloud. That might mean the right GPU classes, storage patterns, queue systems, container commands, or runtime flags are already in place before you ever touch the configuration.
From a usability point of view, the big win is predictability. A recipe defines the container image, resources, networking, and other deployment settings, which helps deployments behave consistently across SaladCloud's distributed fleet of machines.
The same recipe that powers a quick single-replica test can then be scaled across many replicas without turning into a completely different deployment architecture. By codifying important details directly into the template, recipes reduce the odds that something "mysterious" happens only when you scale or only on certain device types.
The First-Run Experience
The first-run experience is deliberately streamlined.
In the SaladCloud Portal, you choose your organization and project, move to Container Groups, and create a new deployment. The UI lets you pick a recipe from the recipe catalog. SaladCloud Documentation
Once you click into a specific recipe, you are looking at a deployment form that is already wired with defaults chosen for a good experience. You can accept the recommended configuration and deploy immediately, or start adjusting replica counts, hardware requirements, and other parameters to match your use case.
Either way, you are never staring at a blank form wondering which fields matter and which ones are purely optional.
That balance between opinionated defaults and controlled customization is where recipes really shine. They are not locked-down black boxes.
Under the hood, a recipe still produces a normal Container Group that you can edit and evolve. You might keep the same resource profile but swap in your own container image, or keep the same startup command but tweak environment variables and connect it to your existing data pipeline.
Because the recipe structure is consistent, those customizations feel like guided changes instead of risky surgery. You stay inside guardrails designed for the platform rather than creating an entirely new deployment from scratch.
Operational Benefits
Operationally, recipes help keep ongoing work much calmer.
Each recipe is designed around how SaladCloud expects workloads to be deployed and managed, including configuration such as health probes where appropriate. Once your Container Group is running, you can use the Portal to monitor its status, inspect logs, edit the deployment, and scale replicas just like any other workload.
Another important aspect of usability is how recipes interact with cost. There is no separate billing surface for recipes. Once deployed, they are billed exactly like any other Salad Container Group: based on the amount of time your workload replicas are running. SaladCloud Documentation
That simplicity lets teams experiment with recipes during early validation without worrying about a separate pricing model. If you already understand how SaladCloud charges for Container Groups, you already understand how recipes show up on your bill.
Recipes Are No Longer Just AI Model Templates
Recipes have also expanded quite a bit.
The current SaladCloud Recipes repository includes templates for image and video generation, LLM inference, model training, computer vision, scientific computing, agent infrastructure, and other GPU-heavy workloads.
There are recipes built around ComfyUI, vLLM, SGLang, llama.cpp, Unsloth, YOLO, GROMACS, OpenMM, Wan 2.2, and other tools and models.
That matters because a useful recipe is often much more than "start this model."
Real AI deployments frequently need startup scripts, model loading, health checks, API servers, environment variables, storage configuration, queues, or framework-specific runtime arguments.
Packaging those decisions into a reusable recipe turns a collection of infrastructure knowledge into something another developer can deploy in minutes.
Community and Collaboration
The recipe ecosystem is also designed to be collaborative.
All of the Dockerfiles and configuration that power these templates live in the public SaladCloud Recipes GitHub repository, where you can inspect implementation details, track changes, and see exactly how a particular template is built.
When you deploy a recipe, a README specific to that workload appears on the Container Group's page, giving you documentation right where you operate the deployment.
The project has also expanded beyond recipes maintained only by Salad. Partner and community recipes can be submitted to the platform, allowing developers who already know how to run a particular application well on SaladCloud to package that knowledge for others.
From Infrastructure Knowledge to a Reusable Building Block
Running a container is easy. Running it reliably, efficiently, and repeatedly is where the work usually starts.
Which GPU should you use? How much memory does it actually need? Which server arguments work best? What health probe should determine whether the workload is ready? How does the model get loaded? How should requests reach the application? What changes when you go from one replica to fifty? Someone has to answer all of those questions.
A good recipe captures those answers once. For a new user, that means starting with a working deployment instead of a blank configuration. For an experienced user, it means having a reproducible baseline that can be customized rather than rebuilding everything each time. And for partners or community developers, it provides a way to package the operational knowledge they already have and make their application easy for SaladCloud users to deploy.
The Bigger Picture
Distributed computing naturally introduces complexity. Machines are heterogeneous, nodes can come and go, hardware availability changes, and workloads need to be designed to operate across infrastructure that does not look like a traditional fixed GPU cluster.
That does not mean every developer using distributed compute should have to think about all of that complexity.
Recipes are one of the layers that hide it.
They turn SaladCloud's distributed hardware and platform capabilities into predictable, repeatable deployment patterns. Instead of learning every detail of the underlying infrastructure before you can run your first workload, you can start from something that already works, understand it, modify it, and scale from there.
For teams that care about usability, that means less time wrestling with infrastructure and more time actually building with the compute.