Containers provide a portable and immutable format for packaging, deploying, and managing cloud-native applications at scale. Salad Container Engine (SCE) offers fully managed container orchestration, dynamically distributes workloads to optimal hardware cohorts in accordance with technical requirements, and features 3D-accelerated GPU processing on every available node instance.
It's the fastest, simplest, and most affordable way to run containerized workloads—without managing virtual machines or underlying compute infrastructure.
To more easily integrate with your existing workflows, Salad offers two methods of creating and managing your deployments:
The Portal is a browser-based UI at https://portal.salad.com that allows you full control over your deployments, including create, read, update, and delete functionality. The Portal also provides access to organization management, billing, and support.
When you are ready for a deeper integration, the Salad API also offers full control over your deployments. Occasionally, new features are made available from the API before they are visible in the Portal. You can dive directly into our API documentation here.
In the Salad Container Engine lexicon, container deployments are known as Container Groups. Each Container Group represents a set of "identical" Container Instances that each run on dedicated hardware.
A Container Group is defined as a container image, the required hardware resources, and a predetermined number of replicas to be maintained at any given time. Once a Container Group has been defined, SCE automatically creates or purges Container Instances as needed to reach the desired replica count.
Container Groups can be created, started, stopped, or scaled via the Salad API and UI, giving you direct control over your workloads before and after deployment.
A Container Instance represents a single instantiation of a container on a dedicated host connected to the Salad network. Each time a container is deployed to a Salad machine node, a new Container Instance is created with a unique id and discrete logs.
Salad leverages hardware-native virtualization and industry-standard container runtimes to standardize the compute environment across a distributed network of heterogeneous hardware.
Once a container image has been deployed, SCE instantiates replicas on a predetermined number of available physical devices as stateless processes within virtual Linux subsystems.
All SCE container instances deploy to consumer-owned hardware running modern Windows NT operating systems (Windows 10 or later). This allows the Salad desktop client to leverage Microsoft Hyper-V virtualization features, manage and monitor workloads, and boot true Linux kernels from the Windows Subsystem for Linux (WSL2).
Currently, SCE supports Linux containers on AMD64 (also commonly known as x86-64). Container image manifests must be Docker compliant (e.g. Docker image manifest v1 or v2). ARM architecture is not supported at this time.
Active SCE container instances are treated as stateless workloads. Whenever the virtual execution context closes (through downscaling, batch job termination, or failure), the container image is purged from the host machine's local memory. While running, the Salad container orchestrator uses heartbeat monitoring to assess potential interruptions or other failures, and determine when and how best to dynamically fail over to another dedicated node to maximize resource availability.
Salad incorporates battle-tested and incrementally developed tooling for reliable performance and replicable results. The Salad API conforms to OpenAPI specifications and generates templates in various coding languages to facilitate testing and development. When deployed from the Salad API or the SaladCloud UI, SCE container instances are automatically executed in the latest stable version of the open-source containerd container runtime.
Salad's affordable infrastructure is as versatile as your imagination. Here are just a few examples of what you can build with SCE:
- use AI models to perform image generation, text to audio, image captioning, and other tasks
- proxy video-streaming requests for virtual private networks
- conduct long-running data processing queues
- execute hyper-threaded, parallelized workloads
- distribute 3D rendering or VFX queues
- procedurally-generated mapping simulations
- access low-latency servers for P2P gaming
Developers interested in using SCE should be aware of these additional considerations:
In rare cases, if the Windows Subsystem for Linux utility is not installed on the best available host machine, the Salad Bowl daemon must install it before running container workloads within Salad's Linux distribution. This design pattern can introduce modest overhead in terms of cold-start time, but should not impact performance or reliability.
Customers in specialized industries may be legally obligated to protect sensitive data such as medical records or private financial information. While Salad takes precautions to secure every workload on our network, we cannot guarantee that our solutions are considered compliant with requirements outlined by select regulatory commissions or legislative authorities (including but not limited to HIPAA and the Financial Modernization Act of 1999).
While SCE does maintain a stable replica count within a given Container Group, SCE deployments do not currently auto-scale Container Groups based on performance. Container Groups must be scaled up or down on demand through the Portal, or by direct request via the Salad API.
Updated 2 months ago