Introducing the Worker App Runner: Deploy from Git to Edge
For CSPs
Education
Deploying AI applications on Ratio1’s decentralized platform just got a lot easier. We’re excited to unveil the Worker App Runner [R1-334] - a new plugin (and Deeploy job type) that lets you run applications directly from source code, without requiring a pre-built container image. This technical yet business-oriented overview will explain what the Worker App Runner is, why we built it, and how it empowers our “Your AI, your Data” paradigm.
Why We Built the Worker App Runner
Traditionally, deploying on Ratio1 required a container image for your app. Our existing Container App Runner plugin assumes you’ve already built and pushed a Docker/Podman image of your application (specified via an IMAGE tag like "my_repo/my_app:latest" in the config). While effective, that approach meant extra work: you had to containerize your code and manage image registries before running anything - a classic and sound CNCF practice that sometimes can be seen as an overkill as for many developers and data scientists, this container prep can be a hurdle.
What if you just want to quickly run your code on the edge to test a new model or microservice? Spinning up a full CI/CD pipeline or maintaining a container registry for every tweak is cumbersome. We realized we needed a more agile way to go “from Git repo to running application” in one step.
That’s why we developed the Worker App Runner. It eliminates the friction by letting Ratio1 handle the containerization on the fly. You provide your code (Git repo link) and how to build/run it, and the platform takes care of the rest. This innovation aligns with our decentralized philosophy: you maintain control of your code and deployment process, with less reliance on external infrastructure.
What Is the Worker App Runner?
The Worker App Runner is a new plugin available in the Ratio1 Deeploy system as a job type. (Recall that Deeploy is Ratio1’s decentralized managed orchestration layer - think Kubernetes, but powered by blockchain and a peer-to-peer node network - more information at https://ratio1.ai/blog/decentralized-cloud-computing-and-beyond and the more recent blog at https://ratio1.ai/blog/deeploy-unlocked-accessing-the-power-of-ratio1.
In simpler terms, the Worker App Runner is a job you can launch on the Ratio1 network which will fetch your application’s code, build it and run it inside a container on an edge node, without you having to pre-build that container image.
Just like our standard container runner (ie. the Ratio1 CONTAINER_APP_RUNNER), the Worker App Runner still uses container technology under the hood for consistency and isolation. It inherits all the capabilities of the Container App Runner - for example, it can allocate a host port and expose your app via a secure Cloudflare tunnel if you’re running a web service. It also supports environment variables, resource limits (CPU, GPU, memory), automatic log capture, and other features you’re used to in Ratio1’s runtime plugins.
The key difference: With Worker App Runner you don’t supply a finished image, you supply a code repository and build instructions. The plugin will start a base container image (by default a lightweight Node.js LTS on Alpine Linux, though you can specify any base image), then clone your Git repository into that container and execute a series of build and run commands that you provide. In essence, it automates what a Dockerfile or devops script might do, but at runtime on the target node.
How It Works: On-Demand Build & Run
When you launch a Worker App Runner job, here’s what happens step by step (all automatically orchestrated by the plugin):
1. Base Container Launch: The system pulls and starts the specified base image (for example, node:lts-alpine by default, or you might use python:3.10-slim for a Python app). The container is started in a paused state (often via a dummy command like a sleep loop) to keep it running while we set up your app inside.
2. Code Retrieval: Next, the Worker App Runner clones your Git repository into the container’s filesystem. Under the hood, it runs a command equivalent to:
This brings in all your application code. (Private repos can be accessed using a token in the URL, which the plugin supports.)
3. Build Commands Execution: After cloning, the plugin executes the list of build and run commands you provided in the config. This could be anything needed to install dependencies and launch the app. For example, you might specify ["npm install", "npm start"] for a Node.js project, or ["pip install -r requirements.txt", "python main.py"] for a Python project. These commands are run inside the container one by one. Essentially, the Worker App Runner composes a shell command chaining your steps with && (and has logging to show each command running). In this way, it replicates the steps of building the app environment just as you would on a fresh machine or in a Dockerfile, but does it live on the node.
4. Application Starts Serving: Once the build commands finish, your application is up and running inside the container. If you configured a network port for the app, the plugin will have mapped it and (optionally) established a cloudflare tunnel automatically so the service is reachable externally. Logs from the app are streamed and captured by the plugin in real-time, so you can monitor output from the Ratio1 dashboard or CLI just as with any other job.
5. Monitoring and Lifecycle: The Worker App Runner keeps the container running and can restart it if needed (for example, if you issue a restart command, or if in the future we add auto-redeploy on new git commits). When you stop the job, the plugin will gracefully shut down the container and save logs to disk, ensuring you have a record of what happened.
All these steps happen seamlessly once you kick off the job. In practical use, it means you can deploy code to the edge in one click - you point to your repo and the platform handles container setup, building, and launching your app.
Decentralization and "Your AI, Your Data"
One of the most powerful aspects of Ratio1’s platform is our commitment to decentralization and user control. The Worker App Runner is built with that same ethos in mind. By allowing you to deploy straight from your own code repository, we’re enabling a workflow where you remain in full control of your AI application and data. There’s no need to upload your code to a third-party service to build an image, nor to rely on a centralized CI/CD pipeline. Everything runs on the distributed Ratio1 network under your direction.
This aligns with our mantra: “Your app, your data” (or as we often say in AI context, “Your AI, your Data”). In other words, you decide where your application runs and where your data stays. Ratio1’s decentralized infrastructure (often described as a “MetaOS” or operating system for decentralized AI) ensures that your workloads can run on permissioned or dedicated nodes if needed, providing compliance and privacy, while still benefiting from cloud-like scalability. The Worker App Runner extends this paradigm by making deployment easier without sacrificing that sovereignty. Your code stays yours - you’re simply instructing the Ratio1 network to run it as a job, with no central cloud provider in the middle extracting your code or data.
Moreover, because Deeploy is blockchain-governed and peer-to-peer, there’s transparency and trust in how your job is executed. The addition of this new job type doesn’t change the security model: your app runs in a container sandbox on the chosen nodes, and if it’s a service, it’s exposed via secure tunnels rather than public IPs. This means you get both ease of deployment and peace of mind that the underlying platform remains decentralized and secure by design.
Comparing Container App Runner vs. Worker App Runner
You might be wondering when to use the traditional Container App Runner versus the new Worker App Runner. Both have their place, and here’s a quick comparison:
Deployment Input: The Container App Runner expects an existing container image name (IMAGE), which you or someone must have built beforehand[2]. In contrast, the Worker App Runner expects a Git repo URL and build commands, and it handles creating the containerized environment at runtime[5]. No pre-built image is needed - just your source code.
Use Case: Container App Runner is ideal if you already have a Docker image (perhaps built by your CI pipeline or downloaded from a registry) and you want a fast startup. It’s basically “bring your own container.” Worker App Runner is ideal for development and continuous deployment scenarios - when you have an app in source form and want to deploy quickly or frequently update it without managing images. It’s “bring your own code.”
Speed: Because Container App Runner skips the build step (it just pulls & runs the image), it might launch slightly faster, especially for large applications where building from source is time-consuming. Worker App Runner has an initial build phase on first run; however, subsequent runs can reuse cached layers (since Docker will cache the base image and any OS-level packages). If your build commands are efficient (or your repo is small), the overhead is minimal for the convenience gained.
Flexibility: Worker App Runner offers more flexibility for tweaking and iterating. Want to test a quick code change? Just push to your repo and (in a future update) the Worker runner could detect the new commit and redeploy your app automatically. Even without automatic triggers, it’s very easy to redeploy with new code; no need to rebuild a container image manually. On the other hand, Container runner might be preferred for very stable components that rarely change or for third-party images you trust (databases, etc.).
Volume & File Access: Both plugins allow mounting volumes if needed, but the Worker App Runner by design works with ephemeral code inside the container. If your app needs to save state or results, you can map a host directory into the container (just as with Container App Runner) for persistence. Both support environment variables and resource configs similarly, since Worker inherits those settings from the base plugin.
In summary, Container App Runner = bring a container; Worker App Runner = bring your code. They complement each other. We expect many users will use Worker App Runner for their own custom apps and AI models, while still using Container App Runner for standard services or when sharing pre-built images.
Streamlining Edge Deployment with Build Automation
From a workflow perspective, the Worker App Runner can significantly streamline your deployment pipeline. Consider a common scenario: you’ve developed a new version of your AI microservice on your laptop. Previously, deploying it to Ratio1 would involve writing a Dockerfile, building an image, pushing it to a container registry (with proper tags), and then updating your Deeploy job to use that new image. With Worker App Runner, you skip several of those steps:
No manual image build: Just push your code to a Git repository (or even work off a branch), and point the Worker App Runner to that repo. The “build” happens automatically on the target node. This reduces the need for Docker expertise or build servers on your end.
Faster iteration: Because deployment is as easy as pointing to new code, you can iterate faster. Early testing, QA, or demo deployments can be done by anyone on the team with minimal devops overhead. This lowers the barrier for experimentation on real distributed hardware.
Consistent environments: The base images (like official Node, Python, etc.) provide a known starting environment, and your specified commands ensure the environment is set up exactly as your app needs. In a way, Worker App Runner acts like an automated container factory each time you deploy. This consistency can be easier to manage than, say, running code directly on VMs or bare metal - you still get the benefits of container isolation and reproducibility, without having to hand-craft the container each time.
Reduced external dependencies: Because the build and run happen within the Ratio1 network’s nodes, you might not need external CI/CD services for building images. Of course, you can still use them if you prefer, but it’s now optional. Ratio1 is providing a form of integrated build automation as part of the deployment process. This can simplify your tech stack and potentially cut costs or complexity.
Commercially, this means faster time-to-market and lower ops overhead for projects running on Ratio1. Teams can focus on writing code and training models, knowing that deploying those to production (or edge locations) is not a bottleneck. In edge AI scenarios - where you might need to update models or logic frequently across many distributed nodes - the ability to automatically rebuild and roll out from source is a game-changer. It brings cloud-like continuous delivery to a decentralized infrastructure.
Balanced Innovation: Technical Power with Commercial Appeal
The Worker App Runner exemplifies the kind of balanced innovation we strive for at Ratio1. On the technical side, it provides a powerful new tool for developers to deploy AI and software workloads in a decentralized manner, automating containerization and leveraging our robust on-chain orchestration. On the commercial side, it adds tangible value for organizations by simplifying devops workflows and speeding up delivery. This feature can reduce the time and skill needed to deploy complex applications across distributed infrastructure - translating to lower costs and quicker iterations for businesses.
By bridging the gap between raw container tech and developer-friendly automation, we’re making the Ratio1 platform more accessible and flexible. Businesses adopting Ratio1 can now onboard projects faster, even if their teams have limited container expertise. And they do so without giving up the advantages of decentralization. In fact, the decentralized nature of Ratio1 is a selling point here: you get cloud convenience without central cloud lock-in. As highlighted in a recent case study, Ratio1’s approach gives users fine-grained control and transparency, aligning infrastructure with a decentralization ethos. The Worker App Runner continues that mission - you control your AI and your data, and now you have an easier path to run that AI wherever your data is.
Conclusion
The introduction of the Worker App Runner plugin marks an exciting step for the Ratio1 ecosystem. It’s not just a new feature - it’s a statement that deploying AI applications can be both easier and more autonomous. By allowing code-first deployments on our decentralized network, we empower users to move quickly while retaining control. Whether you’re an indie developer iterating on an AI model, or an enterprise rolling out edge services across many locations, this new job type will streamline your workflow and enhance your ownership of the process.
We invite our community to try out the Worker App Runner and share feedback. It will be available in the Deeploy dashboard as a selectable job type in the upcoming release. We believe it will become a cornerstone for many deployments, combining the best of cloud agility with the unique strengths of Ratio1’s decentralized platform. With features like these, we continue to drive toward a future where AI is powered by you - your code, on your data, running where you decide, with Ratio1 handling the heavy lifting in the background.
Stay tuned for more updates as we integrate automatic redeploys on code changes and other enhancements to the Worker App Runner. In the meantime, say goodbye to the friction of manual container builds and hello to a new era of frictionless edge deployment on Ratio1. Your AI, your data, your deployment - now just one git push away from reality.
Vitalii Toderian
Sep 5, 2025
