> For the complete documentation index, see [llms.txt](https://docs.release.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.release.com/getting-started/create-application/servers-vs-runnables.md). # Servers vs runnables Learn the difference between servers and runnables When setting up applications in Release, it's essential to understand the differences between servers and runnables to choose the right execution type for your needs. Here's a detailed explanation of both. ![](https://585411240-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M1neGLLQ0sDXeK6ooSo%2Fuploads%2Fgit-blob-31fc77c242205e239fcd07cbaaef0a5dd6921564%2Frunnable-and-server.png?alt=media) ## Servers Servers in Release are designed to run continuously, providing a persistent environment that ensures your application is always available. This makes them ideal for applications that require a stable, long-term setup, such as web servers, databases, or services that need to be operational 24/7. The primary advantage of using a server is its reliability and stability. Because servers are always running, they can handle tasks that require constant uptime and immediate responsiveness. This is particularly useful for hosting websites, APIs, or backend services where downtime could impact users or business operations. Another key feature of servers is their ability to maintain state between restarts. This means they can preserve data, sessions, and other critical information, which is essential for applications that need to retain user data or track ongoing transactions. Scalability is also a strong suit of servers. They can be scaled to handle increased load, ensuring consistent performance as demand grows. This makes them a suitable choice for applications expecting high traffic or usage spikes. ## Runnables Runnables are designed for on-demand execution. They are perfect for tasks that do not require a continuous run but are triggered to perform specific operations as needed. When a runnable is called, it starts, completes its task, and then shuts down, making it highly efficient for short-lived processes. The primary benefit of using runnables is resource efficiency. Since runnables only run when needed, they consume fewer resources compared to servers that run continuously. This can lead to cost savings and more effective resource management. Runnables are typically stateless, meaning they don’t retain information between executions. This makes them ideal for tasks like batch processing, data transformation, or executing microservices that perform specific, isolated functions. Because they don’t need to preserve state, runnables can start up quickly, perform their designated task, and then shut down, ensuring prompt completion of tasks. In addition to their efficiency, runnables are well-suited for scheduled tasks or automated workflows such as data processing jobs or CI/CD pipelines. This makes them a versatile option for various automated processes that need to run at specific intervals or in response to certain triggers. ## Choosing the execution type If your application needs to be available continuously, handle persistent data, or serve real-time user requests, a server is the best choice. If your tasks are intermittent and can benefit from resource efficiency, runnables are the better option. | | Servers | Runnables | | ------------------ | ------------------------------------------------------- | ------------------------------------------ | | **Execution Type** | Continuous, always running | On-demand, runs as needed | | **Use Case** | Web servers, persistent services, LLM hosting | Batch jobs, microservices, LLM fine tuning | | **Resource Usage** | Higher resource consumption due to continuous operation | Resource efficient, runs only when needed | | **Scalability** | Can be scaled to handle increased load | Efficient for short-lived tasks | | **Management** | Suitable for applications needing constant availability | Ideal for scheduled or triggered tasks | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.release.com/getting-started/create-application/servers-vs-runnables.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.