# Juggle: interface orchestration where a flow is edited in the browser, not in a repository

> Juggle stores API composition as flow definitions edited in a browser rather than code committed to a repository, and its node set covers Http, Dubbo, WebService, SQL, cache and message queue work in one graph. Its own setup instructions disagree on the archive suffix, and the Compose file mounts a config path the repository does not ship.

**somta/Juggle** — A powerful no-code/low-code AI orchestration platform for microservice API orchestration and system integration, supporting HTTP, Dubbo, WebService and other protocols, scriptable with Groovy, JavaScript, Python, Java and more, and compatible with MySQL, DM and other common data sources.

- Repository: https://github.com/somta/Juggle
- Website: https://www.juggle.plus
- Stars: 1,161 · Forks: 203
- Language: Java
- License: GPL-3.0
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/somta-juggle

## Ten node types carry the calls, the branching and the SQL

Ten node types carry the work of a flow. The method node is the only one that reaches outside: it picks an interface defined inside a suite, assigns request headers and arguments from variables, and binds response fields back into variables that later nodes read. A judgment node holds several branches, one of which is always an else branch, and the branches are mutually exclusive and evaluated from left to right. A loop node contains other nodes, so a collection produced upstream can be handled item by item, the shape needed when each record lands in a different table. An assignment node sets different values on one variable under different branch conditions, and a call node points at a finished sub flow so shared logic is edited once. A code node accepts Groovy, JavaScript, Python or Java for variable assembly and data cleansing. A queue node writes to a message queue, and a cache node keeps an interface response in flow-wide cache.

One node is named twice, and the two descriptions do not line up. The feature list calls it the MySql node. The node section calls it the database node and says it connects dozens of data sources. The same feature list puts the supported database count at nearly ten, naming MySql, Dameng, TiDB, OceanBase and Doris. Ten and dozens are different figures, and nothing in the repository says whether the wider count means more drivers or more connection parameters per driver. The node is aimed squarely at systems with no API to call, such as an old system reachable only through SQL, data cleansing runs and big data jobs.

## Only the parallel node starts virtual threads, and only for one strategy

Concurrency is confined to a single node. The parallel node accepts several interfaces on one node and lets the author choose an execution strategy, and when the parallel strategy is picked the server starts several virtual threads to make those calls. That is the whole concurrency story in the documentation: there is no thread count setting, no queue depth, no per branch timeout, and no statement about what happens when one branch fails while its siblings succeed.

The runtime floor is pinned by the Java version. The build badge asks for Jdk-21, the setup section asks for a 64 bit JDK 21 on a 64 bit OS with Linux, Unix and Mac preferred over Windows, and the container image builds on an Alpine layer carrying Eclipse Temurin JDK 21. Heap size is not derived from your workload, because the image fixes both the initial and the maximum heap at 1g, sets the young generation to 128m and the survivor space to 320m, and switches the GC log off through an environment variable. A larger deployment has to edit those variables, since no other sizing path is documented.

## Four flow kinds split on who receives the result, not on how it is drawn

Flow type decides who gets the answer. A synchronous flow returns its result to the caller inside the same call, which suits interface composition and BFF endpoints where latency matters. An asynchronous flow does the opposite: the caller has to go to a different interface to collect the result, which suits slow work such as data cleansing. The README does not name that result interface, its path, its authentication, or how long a finished result stays retrievable, so wiring a caller against it is left to whoever deploys the server.

A scheduled flow runs at a fixed time or on a period, and the result is not the point, periodic data synchronisation being the stated case. A listener flow waits for a message from a business system MQ and runs on arrival, with data cleansing and data annotation given as the situations. Those last two share one dependency, and no broker product is named anywhere: no Kafka, no RabbitMQ, no RocketMQ appears in the documentation, and there is nothing about redelivery or dead lettering. If your stack runs one specific broker, confirming it works is work to do before flow design starts.

## A suite market supplies ready interfaces while versioning covers staged rollout

Two features cut down on design time rather than on runtime work. Flow multi version management is the first, and it arrives with what the documentation calls natural support for staged flow rollout, so a new definition can sit beside the one currently serving traffic. The suite market is the second: it carries dozens of official suites for common systems, and four are named, Tongyi Qianwen, the DingTalk robot, QQ Mail and Aliyun SMS. A method node that posts to a DingTalk robot then points at a ready definition instead of an HTTP request assembled by hand.

Four situations are given as the fit. Teams with existing service capability can assemble a new product on top of it. A third party system can be connected by composing calls, with no integration code written for it. A BFF layer can sit in front of the frontend in place of the usual Node.js implementation. A product needing private deployment or heavy customisation can keep that variation in flows rather than in standard code.

Read the project description before expecting machine learning features. It presents itself as an AI oriented orchestration platform and its topics include ai, yet the only AI surface in the README is that single Tongyi Qianwen suite. No AI node appears among the ten, and no model call appears in the quick start.

## The download line names a zip and the Linux command untars a tar.gz

Install path one, the archive. Juggle needs Java first: a 64 bit OS running Linux, Unix, Mac or Windows, with Linux, Unix and Mac preferred, plus a 64 bit JDK 21. The package comes from the latest stable version page as `juggle-server-$version.zip`, which Windows users unpack with any archive tool. The command given for Linux, Unix and Mac is:

```bash
tar -xvf juggle-server-$version.tar.gz
```

Those two sentences do not agree. The download instruction names a zip file, the command unpacks a tar.gz, and tar cannot read a zip archive, so one of the two instructions fails as written and the README does not say which one. The first command a Mac user runs is where it surfaces.

Install path two, the service. The start scripts sit in the `juggle/bin` directory. Windows users double click `startup.cmd`, and on Linux, Unix and Mac the same step is:

```bash
sh startup.sh
```

Once the server answers, open `http://127.0.0.1:9127` in a browser and sign in with account `juggle` and password `juggle`. Sample interfaces and a sample flow ship with the system, and their definitions live on the project documentation site rather than in the repository, so the first working call comes from that sample rather than from something you build.

## Port 9127 and the juggle account arrive without documented hardening

A default install is one jar on one port. The image copies `console/target/*.jar` into `juggle-server.jar`, exposes 9127 and runs `/home/juggle/bin/docker-startup.sh` as its entry point, and the embedded database file `db_juggle.mv.db` is placed in the data directory at build time. Three separate places name the same port: the browser address in the setup instructions, the EXPOSE line in the image and the published port mapping in the Compose file. Moving off 9127 therefore means changing the configuration and the deployment manifest together.

The login waiting on that port is account `juggle` with password `juggle`, delivered over plain `http://127.0.0.1:9127`. Nothing in the repository documents changing that password, binding the listener to another interface, placing a certificate in front of the server, or restricting who may reach the designer. For a private deployment, which is one of the four situations the project is aimed at, that belongs at the start of the work rather than at the end of it.

## The Compose file mounts a config path the repository does not contain

The container path needs preparation before it will run. The Compose file is eight lines long:

```yaml
version: "3"
services:
  juggle:
    image: somta/juggle:latest
    ports:
      - 9127:9127
    volumes:
      - ./conf/application.properties:/home/juggle/conf/application.properties
```

Apart from the ignore file and the legal text, the top level of the repository holds Dockerfile, README.md, console-ui/, console/, docker-compose.yml, docs/, example/, issue_template.md and sdk/. No conf directory appears in that list, and the file the Compose file expects on the host is not shipped at the top level. The default configuration the image falls back to is copied in from `console/src/main/resources/data/application-default.properties`. A bind mount over a host path that does not exist shadows the default the image already carries, so a fresh checkout plus a Compose run needs that configuration created by hand.

Two smaller points travel with it. The tag is `latest`, a moving target, while numbered archives exist beside it, so a Compose deployment pins nothing about which build it will pull. And the base layer is `registry.cn-hangzhou.aliyuncs.com/somta/baseimage:eclipse-temurin-jdk-alpine-21.0.5_11`, a project owned registry path rather than a public image name, so building the image yourself needs access to that namespace.

## An sdk directory and two example apps with no documented calling path

The repository carries calling code that the setup guide never uses. Alongside the server and the browser console, the top level includes an `sdk/` directory and two sample projects, `example/juggle-nodejs-example/` and `example/juggle-spring-boot-example/`, which are the Node.js and Spring Boot integrations. The quick start stops at the browser, and nothing in the README shows a caller invoking a published flow, passing a flow token, or handling an error response from a flow endpoint. The demo environment at `https://demo.juggle.plus/#/login` accepts a Gitee or GitHub sign in and sits on a separate host from the server you started, so that is the only place the HTTP calling convention becomes visible.

Three facts frame the rest of an evaluation. Work happens on the `develop` branch, so patches and forks target that branch instead of master or main. Juggle is published under GPL-3.0. The last push to the repository was on 2026-09-14.

## Conclusion

Juggle earns its place where the work is composing calls that already exist rather than writing new services: the node set covers Http, Dubbo, WebService, SQL and queues, and versioned flows suit a product whose frontend changes often. It does not suit a team that wants one codebase, since the composition lives in a running server and its designer. Check which archive suffix your platform downloads, since the two setup instructions disagree, then which broker the queue and listener nodes accept, since none is named, and whether the juggle password is changed before the port leaves your own machine.

## FAQ

### What is Juggle used for?

Juggle is a low code interface orchestration tool that composes several simple APIs into one complex interface, which a frontend can call directly. It also works as a BFF layer in place of a Node.js implementation, connects third party systems without integration code, and keeps product customisation in flows rather than in standard code.

### How do I install and start the Juggle server?

Install a 64 bit JDK 21, download the server archive from the latest stable version page, unpack it, and run the start script in the juggle/bin directory. On Linux, Unix and Mac that script is run with sh startup.sh, and the designer then answers on http://127.0.0.1:9127 with account juggle and password juggle.

### Which databases can the Juggle database node connect to?

The feature list names MySql, Dameng, TiDB, OceanBase and Doris and puts the total at nearly ten databases. The node section for the same node says it connects dozens of data sources, and the repository does not explain the difference between the two figures.

### Which message brokers do the Juggle queue node and listener flows support?

A queue node writes to a message queue and a listener flow runs on messages from a business system MQ, but the README names no broker product at all. Confirming that your broker works is a question for the maintainers before you design a flow around it.

### What are the default credentials for the Juggle web console?

The setup instructions give account juggle and password juggle at http://127.0.0.1:9127. The repository does not document a procedure for changing that password or restricting who can reach the listener.

## Sources

- [License: GPL-3.0](https://github.com/somta/Juggle/blob/develop/LICENSE)
- [Project website](https://www.juggle.plus)
- [README](https://github.com/somta/Juggle/blob/develop/README.md)
- [Releases](https://github.com/somta/Juggle/releases)
- [somta/Juggle on GitHub](https://github.com/somta/Juggle)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/somta-juggle