Have you ever considered running your Workflow on a server accessible to everyone, sharing your work with others, or running your Workflow as a background service for easy invocation at any time?

Now you can achieve this with OOMOL Studio. In this article, I will detail how to export a Workflow as an image and run it in the background. I will implement a Workflow that translates a PDF and converts it to an EPUB e-book, allowing me to read literature from foreign authors on my mobile device without language barriers.

You can download the specific Workflow implementation from translate-pdf-to-epub. You can follow this article to run the Workflow as a service on any computer or cloud platform you want.

To read this article, you need basic knowledge of image containers.

Workflow Development​

If you already have a completed Workflow, you can skip to Export Image

The functionality can be broken down into the following steps:

1. Convert a PDF file to an EPUB file.
2. Translate the converted EPUB file.
3. Save the translated EPUB file to a specified location.

The process is simple, and we will use existing Blocks from the OOMOL community.

First, we create a project called translate-pdf-to-epub, then install the following Packages from the store:

pdf-craft

books-translator

Then, we use the Analys PDF and Genrate EPUB Blocks from the pdf-craft Package, and the Translate epub book Block from the books-translator Package, chaining them together to form the Workflow.

The Workflow is now complete. Next, we need to fill in the parameters. The following parameters are required:

1. The path of the PDF file to process
2. The output path for the final EPUB file

The Translate epub book Block's default output language is Chinese. Adjust the parameters as needed.

You can clear the output_dir parameter to store intermediate products in memory. Closing the application will release them.

Since the PDF file input requires a PDF address, we need to place the PDF file to be processed into the OOMOL Studio environment so the application can read it. Copy the file into the OOMOL space from the left panel:

Then, select the PDF file address and the output EPUB file address and extension:

Next, run the Workflow. After some time, you will see the output file, and the content will be translated.

You can see the article has been translated into Chinese.

At this point, we have developed and run a Workflow. Currently, the Workflow can only run inside the OOMOL Studio application. Next, we will detach the Workflow from the OOMOL Studio environment and run it independently.

Export Image​

Return to the OOMOL Studio Home page, find the Workflow you just developed, right-click and select Export as Image, choose the export folder, and after a while, you will get an image file with the same name as the Workflow.

Running the Image​

After obtaining the image file, use the docker command to load the image file. In the terminal, run

docker load -i ~/Downloads/translate-pdf-to-epub.tar.zst  # Use the path where you saved the image file

After running, you can find the image:

Since the image runs outside OOMOL Studio, we cannot identify the user running the container. The current Workflow uses AI for translation, and OOMOL will convert the translation cost into credits. Using an API-key allows the credits to be deducted from the corresponding user's account, enabling the Workflow to run normally.

If the Workflow does not use built-in services like AI, or uses your own AI service, you still need to pass in the API-key when starting the container, but no credits will be deducted.

You can generate an API-key in the OOMOL Console.

Once the API-key is hidden, it cannot be retrieved again. Please keep it safe.

After obtaining the API-key, run the following command to start the container:

docker run --privileged -p 3000:3000 -e OOMOL_API_TOKEN={OOMOL_API_TOKEN} -v $HOME/oomol-storage:/oomol-driver/oomol-storage localhost/translate-pdf-to-epub:latest

After running the image, you can access the started container at http://localhost:3000. At this point, the previous Workflow is running as a local service.

File Paths Inside the Image​

In this example, the Workflow starts by inputting a file path. However, after the Workflow is exported as an image, all paths inside the image container refer to paths inside the container. If you directly pass a host path to the Workflow, the Workflow inside the container cannot access the file.

Here, we mount the host's $HOME/oomol-storage path to /oomol-driver/oomol-storage inside the container. This way, adding files to $HOME/oomol-storage on your computer is equivalent to placing files in /oomol-driver/oomol-storage inside the container. This allows file exchange between the host and the container.

If you want to deploy the image to a cloud server, you also need to meet this requirement: the Workflow inside the container must be able to access the actual file path. If you find mounting files cumbersome, you can change the input file path to a network address, such as uploading to AWS S3 or other network file management services, then download and read the file inside your Workflow. This way, file access always happens inside the image container, avoiding file-not-found issues.

Calling the Workflow​

After starting the image container, you can use HTTP requests to query, start, and stop the Workflow.

Visit http://localhost:3000/ui to see the HTTP request interfaces exposed by the image container:

For detailed interface descriptions, refer to the API documentation.

Query Workflows​

Use the GET method to call http://localhost:3000/v1/flows to query the list of Workflows in the image container.

The returned content includes detailed Workflow structures, including Node information, input/output Handle names, and types.

Run Task​

Use the POST method to call http://localhost:3000/v1/tasks to run a Workflow and create a task.

As mentioned in Workflow Development, before starting a Workflow, we need to fill in parameters for several Nodes. Here, we pass the parameters in the request:

The flowName / nodeId / handle information for the parameters can be found in Query Workflows.

Here, the input file path is /oomol-driver/oomol-storage/test.pdf. Since we previously mapped the /oomol-driver/oomol-storage folder to $HOME/oomol-storage during Running the Image, simply place test.pdf in $HOME/oomol-storage, and the Workflow can read the file. We name the output file local-service-output.

After the API call, you will receive a task ID.

Query Tasks​

Use the GET method to call http://localhost:3000/v1/tasks to list all tasks in the image container.

Use the GET method to call http://localhost:3000/v1/tasks/{task_id} to query task details by task ID.

You can poll these two APIs to check the task status.

When the task is complete, you will see the task status as completed and view the output result:

Summary​

This article introduced how to export a Workflow from OOMOL Studio as an image and run it independently.

Users can deploy the image in any environment, turning it into a continuously running service. This allows the Workflow to maximize its value, whether on a local server, cloud platform, or in a team collaboration environment, enabling efficient reuse and sharing of automated processes.

Introduction​

In today's rapidly evolving digital era, automated workflows have become a key tool for boosting productivity. From simple task connections to complex business process automation, a variety of tools have emerged to meet users' growing automation needs. However, as business complexity and customization requirements increase, traditional workflow tools are beginning to show their limitations.

Against this backdrop, OOMOL Studio was born. It not only inherits the advantages of existing tools but also achieves revolutionary breakthroughs in key technologies. By supporting a complete coding environment, local execution, image export, and a refined developer experience, OOMOL Studio is gradually approaching the ultimate form of automated workflow tools.

This article will delve into the development of automated workflows, the capability boundaries of current tools, and how OOMOL Studio is becoming the most powerful automated workflow solution through technological innovation.

A Flourishing Tool Ecosystem​

There are many automated workflow tools on the market today, such as Zapier, n8n, Dify, etc. Each tool has a rich community and a large user base.

Zapier connects with over 7000 applications, n8n has more than 2000 templates, Dify has established itself in the AI field, and new workflow tools are constantly emerging. Overall, they all strive to reduce workload and improve efficiency for customers.

Automated workflows are like assembly lines in factories, turning every step in production into reusable units, linking them together, and running them automatically. This achieves clarity, control, and efficiency, ultimately improving productivity and saving time.

The Evolution of Automated Workflows​

Zapier connects various applications on the market as units, including various AI Agents. For most users, the number of connections Zapier offers is sufficient to meet most simple needs, such as reading emails and replying via AI, or reading a spreadsheet and having AI analyze its performance. Many customers' needs stop here, so Zapier is enough.

This is a linear execution process, completing work step by step. In reality, workflows may not be so ideal; the steps are not always strictly sequential, and their relationships are more like a network, where some Nodes may be skipped as needed.

However, business is constantly evolving, and real-world requirements always change. When your target customers change, or a provider in your workflow faces closure, you have to adjust your workflow: either find a replacement provider or implement the functionality yourself.

After automating simple needs, most customers will try to automate more complex and variable tasks. No one wants to be stuck with repetitive work. At this point, workflow platforms limited to fixed applications run into trouble. They can only let developers add new features and release them to users, which usually takes time. Therefore, Zapier provides features like Code and Path, hoping users can solve some special problems themselves.

That's why tools like n8n claim to be more flexible—they support a better code editing experience, and their workflow orchestration is more complex, able to handle more variable problems. In n8n, workflows can be orchestrated freely, with more logic control Nodes such as if and switch. These built-in tools make workflows more flexible and applicable to a wider range of scenarios.

This is the limit of what most workflow tools on the market can do today. They have implemented most programming concepts, making process control very free, and support code so users can meet some small-scale customization needs. Although code cannot rely on third-party Packages, since it runs in the cloud, most people accept this limitation.

OOMOL's Technological Breakthroughs and New Possibilities​

On this basis, most users have completed more complex business. But are there users with even higher-level needs? The answer is yes. Data analysts and scientists invest a lot of effort through Python code, using modules like pandas or numpy to achieve their goals, so most workflows on the market cannot meet their needs.

We can see that, to handle various business scenarios, workflow tools are becoming more and more like programming. After all, programs are Turing complete, which means the closer you get to programming, the more you can do. That's why workflow tools now all introduce code modules.

So why don't they directly support full programming? The reason is that these tools run in the cloud, and supporting code compilation and dependency management in the cloud is very difficult. The more users there are, the more isolated environments are needed, making it impossible to achieve from a cost perspective.

What about local application support? n8n is working on this, but supporting different languages on multiple platforms is still a huge challenge. Objectively, most needs are simple, and automating these needs and charging based on the time saved is already profitable. Investing further in programming support may not be cost-effective.

So why does OOMOL Studio still take on this difficult and uncertain task?

Current workflow tools are full of tasks like converting one file format to another, or generating a message based on search content and posting it to social media. You know these are not the complete business customers want. After converting a file, they need to share or analyze it; posting to social media is to attract users or gain data or revenue, but the remaining steps are too complex for current workflow tools to handle with simple if/else logic.

So it's not that users don't want to automate their business—it's that it's not possible yet.

Therefore, OOMOL Studio supports code so users can truly automate all their business. The Python and Node.js communities have a wealth of open-source solutions for various problems. We hope users can use these existing tools to solve problems, or build automated Flows themselves as needed. We believe that truly high-value work is relatively complex, and the profit customers can earn should depend on the difficulty of the problem and the time saved.

At the same time, local execution can utilize users' own computing resources. Not all workflows require powerful hardware; some businesses are complex but can be handled by ordinary computers. Local execution can save users unnecessary costs.

Difference from Pure Code Implementation​

Since code is Turing complete, why not just write code instead of using OOMOL Studio?

In terms of flexibility, code is undoubtedly the highest. But the business users want to achieve is always time-sensitive. If you implement it by writing code, you need to install a development environment, choose a language and framework, build the application, and then publish and install it—the whole process is an engineering project. For individual users, this is a huge workload, and if requirements change, the process may have to be repeated.

OOMOL Studio has a built-in coding environment. After the workflow is completed, you only need to fill in basic information to publish and share it directly, greatly shortening the time from development to delivery. Users can also adjust any Node at any time, retaining the advantages of workflow tools. This helps users quickly iterate and deliver.

Conclusion​

Let's return to the ultimate goal of automated workflow tools: to have computers automatically run most quantifiable work, evaluate the results, and output them to users, thereby saving a lot of time and improving human productivity.

We don't believe that articles on social media like "I made tens of thousands of dollars with this AI video workflow" are really trying to improve everyone's productivity. Their goal is just your consulting fee, or simply advertising. They only automate the simplest part of a real problem and share it repeatedly. In fact, they do improve productivity to some extent, but the truly difficult part is the customized process that requires manual user involvement.

OOMOL Studio chooses to explore this difficult path. Maybe we are not the ultimate solution, but at least we have made some efforts—giving users who want to truly solve complex problems and automate them the opportunity to achieve their goals.

As the most popular workflow automation platforms currently, Zapier and n8n have saved users a tremendous amount of time from repetitive tasks. They enable individuals and businesses to use numerous built-in Software-as-a-Service (SaaS) tools to expand their operations and improve productivity. They excel as traditional low-code automation platforms, with active communities continuously adding various applications to their platforms, constantly expanding the business scenarios they can accommodate.

Zapier was founded in 2011, focusing on integrating various applications in the market in the simplest way possible, allowing any user to achieve their business objectives by connecting applications. Although Zapier claims to be a no-code platform, it still introduces Code nodes because the inputs and outputs of market applications are incompatible, so programming work is always needed as a glue between applications.

n8n appeared later than Zapier, positioning itself as an alternative to Zapier by claiming to provide better programming support to attract users with technical backgrounds, and this strategy has proven effective. It's evident that fully no-code automated workflows always encounter problems: each user's needs are not exactly the same, existing community solutions cannot perfectly solve users' actual problems, and some fine-tuning is always needed, so both platforms have reached a consensus on introducing code.

However, Zapier and n8n chose cloud-based execution, where cloud-based code editing cannot introduce third-party dependencies, or it's extremely difficult to do so. This already limits their code editing experience from ever reaching the level of freedom they desire. The n8n team may have realized this problem, so they offer self-hosting options that allow users to introduce third-party libraries for code, but their primary cloud-based execution still cannot achieve this functionality.

Therefore, OOMOL Studio took this consensus a step further. As a downloadable application, it runs containers with complete code environments locally, enabling the use of complete Node.js and Python community libraries. Complete code support brings workflow development experience and extensibility to the extreme. At the same time, it limits complexity during use through good interaction design, making it easy for ordinary users to get started.

OOMOL Studio, as the latest workflow platform, inherits the advantages of Zapier and n8n while attempting to approach from a completely new angle to solve the pain points currently encountered by workflow automation platforms.

TL;DR​

Introduction​

• Zapier

Zapier is a no-code, cloud-based workflow platform with over 7000+ built-in applications, allowing users to orchestrate these applications called Zaps to achieve their business objectives.

Zapier's major advantage lies in its massive collection of built-in applications. Reaching this scale of applications is not easy, which has maintained its stable leading position in the workflow automation field.

• n8n

n8n is a low-code, open-source workflow platform that can be self-hosted or run in the cloud, with 1000+ built-in applications and 2000+ templates.

n8n's advantage lies in introducing code in a relatively simpler way, allowing users to conveniently fine-tune workflows. Therefore, workflows produced by n8n are more extensible and flexible compared to Zapier.

• OOMOL Studio

OOMOL Studio is a core open-source workflow platform that supports local/cloud/self-hosting execution methods with perfect code support. Due to its recent release, it doesn't have many built-in applications yet.

OOMOL Studio's advantage lies in its perfect support for Python and Node.js code, meaning it can introduce any Python and Node.js modules in workflows, which is impossible in Zapier and n8n.

Therefore, OOMOL Studio has the highest degree of freedom and extensibility. Even when built-in applications are insufficient, users can quickly build the nodes they want using code to complete their business. After completing business, they can quickly publish code as platform applications for reuse or sharing.

Additionally, OOMOL Studio's local execution method is completely free, which could save most users hundreds of dollars in monthly expenses.

Platform Characteristics and Philosophy​

• Zapier: No-code, easy-to-use, cloud-based

Zapier's cloud-based and no-code characteristics position its target users as non-technical personnel. Users don't need to install applications or consider programming; they just need to break down business into detailed steps, find corresponding apps for each step, connect them, and use.

Of course, it also provides limited code functionality, but this is obviously not their focus since the code here cannot reference community libraries.

Zapier's goal is quick startup and execution rather than deep customization. These characteristics attract a large number of non-technical users and small business users. With AI technology continuously developing today, Zapier focuses on helping users avoid code and quickly implement user business through AI or community applications.

• n8n: Open-source, low-code, easily extensible, self-hostable

n8n has both self-hosting and cloud execution methods.

As an open-source project, n8n allows users to self-host to save operational costs. It has made some progress in code compared to Zapier. In self-hosting situations, n8n can install third-party community libraries for code.

Self-hosting methods can supplement insufficient built-in applications through code and improve workflow flexibility and extensibility, thus attracting quite a few users with coding backgrounds.

High extensibility also facilitates users in integrating continuously updated AI applications.

Cloud execution methods suit non-technical users or users with non-customized business needs, overlapping with Zapier's user base.

n8n has moved one step forward from Zapier toward customizable workflows. Although it increases complexity in user experience, users with coding capabilities provide considerable vitality to the community.

• OOMOL Studio: Containerized, perfect code support, easily extensible, multiple execution methods

OOMOL Studio's goal is to attract users with coding backgrounds, use simple publishing and sharing mechanisms to gradually improve the community, then let ordinary users also enjoy the advantages of workflow automation.

OOMOL Studio expects users to truly achieve workflow automation and improve productivity, so it designed image export methods, enabling user-developed workflows to be deployed to the cloud in users' expected ways.

OOMOL Studio also has built-in mainstream LLMs for direct use. If it cannot meet user needs, users can directly integrate through code.

Cost​

• Zapier

Starting price is free with a limit of 100 tasks per month. The free tier basically cannot meet normal production use.

Paid plans require at least $20 per month. Costs increase based on task execution frequency. If there are many repetitive tasks, costs may rise considerably.

• n8n

Self-hosting is free to use. Cloud execution starts at $20 per month, allowing 2500 task executions per month.

• OOMOL Studio

Application download is free with no limits on execution frequency. LLM resource consumption incurs some costs, but pricing is transparent, and users can avoid these costs by integrating their own LLMs.

Subscription fees start at $5 per month, unlocking more advanced features. Free subscription plans don't affect users' development experience.

Feature Comparison​

1. Workflow Interface​

• Zapier

Orchestrates workflows in a linear manner, generally running in 'trigger' -> 'action steps' format with small operation space and simple, understandable interface.

• n8n

Orchestrates workflows through drag-and-drop, allowing free connection of each work node to specify execution order. This operation method is more complex than Zapier but can orchestrate more complex tasks with higher customization.

• OOMOL Studio

Orchestrates workflows through drag-and-drop while also orchestrating input/output types and values for each node. Compared to n8n and Zapier, it's more complex. Output node values can control workflow execution conditions. But for technical personnel, complexity brings greater flexibility and customization capabilities.

Also provides sub-flow functionality, allowing complex workflows to be simplified into ordinary nodes, enabling users without technical backgrounds to use directly without concerning themselves with details.

2. Customization and Flexibility​

• Zapier

Despite having numerous integrated applications, customized use is limited and difficult to meet special requirements.

• n8n

Has good flexibility, but each node's input is treated as a whole, unable to perform fine-grained control. Customization capabilities are limited as code community libraries can only be introduced in self-hosting mode.

• OOMOL Studio

Ultimate flexibility. Special requirements can be directly implemented using code, or existing community workflows can be used as templates and directly modified to achieve business objectives.

3. Development Experience​

• Zapier

Code modules cannot introduce third-party libraries, can only use built-in language functions, with extremely limited capabilities. Additionally, sending HTTP requests requires payment.

• n8n

Code modules can only introduce third-party libraries in self-hosting mode, requiring prerequisite setup according to files with complex configuration.

• OOMOL Studio

Can directly install any Python and Node.js libraries in terminal, no different from native code development. This means Python and Node.js ecosystems can both be applied to business. Furthermore, Python and Node.js environment libraries can be used together.

4. Running and Debugging​

• Zapier

Logic-wise provides Path functionality to control workflow execution paths but cannot handle complex logical judgments.

Debugging-wise provides test execution mechanisms and simple exception alert mechanisms.

• n8n

Logic-wise provides if/switch components to control workflow execution paths. Combined with code, it can implement relatively complex business logic.

Debugging-wise provides single-point execution and partial execution functions, plus ignore and rollback mechanisms, basically meeting users' development debugging needs.

• OOMOL Studio

Controls workflow execution paths through node outputs. This method is more complex but allows finer-grained workflow control, with each output value processable individually.

Provides individual execution and ignore debugging functions for each node. All execution logs are recorded in detail and displayed categorically in the log panel.

Node exception situations are directly displayed in the interface and logs for easy user observation and modification.

5. Collaboration and Sharing​

• Zapier

Only team plans can share workflows.

• n8n

Can share and export workflows to specified users.

• OOMOL Studio

Can share workflows with the entire community while allowing export/import in multiple ways. Under paid subscriptions, workflows can be jointly published.

Summary​

Zapier attracts numerous users through extensive built-in integrations and simple, understandable process interfaces, while n8n focuses on users with higher customization needs. Both have done their jobs well in their respective fields.

OOMOL Studio recognizes that the real pain point in workflow automation scenarios has long been that users always need some degree of freedom to adjust workflows. OOMOL Studio chooses to implement truly free development experience, as only workflows produced this way can meet various users' needs.

OOMOL Studio hopes users are completely free in both development and use, allowing any scenario to be incorporated into automation scenarios through development adjustments, ultimately benefiting users without technical backgrounds and improving overall social productivity.

OOMOL Studio is certainly not a perfect product, but like Zapier and n8n, it hopes to explore the most suitable way to achieve the goal of automating everything.