Are you looking for help in developing Orchestra?

[JTF4]

Me and a friend of mine would love to help you out if you would like help developing it. We would love to see this project be a success.

[jhuckaby]

Hey @JTF4,

Thank you so much for the offer! I'm currently developing Orchestra in stealth mode (offline), as I did the original Cronicle back in 2015. What I like to do is open source it when it's ready for launch. It's just how I prefer to design and code apps.

That being said, I would love to hear which features you'd like to see in Orchestra. Here is what I have completed or have planned at a high level, beyond the features in Cronicle:

• Orchestra will have a full server monitoring and alerting system built-in
  • Similar to my own Performa app, but much improved and built right in.
• Redesigned server communication system
  • Servers no longer have to be "added" to the UI manually -- they add themselves on startup.
  • This also allows for ephemeral servers like AWS autoscale.
• Redesigned web socket system for the UI
  • The user only requires a connection to the main server. The UI will no longer make direct connections to worker servers.
  • This should solve many problems reported by people with complex network architectures.
• Ship entire app as a compiled Linux binary
  • i.e. no install-time dependencies, not even Node.js
  • You will still be able to install from source if you want.
• Completely redesigned user interface
  • Dark mode / light mode
  • Responsive design for tablet/mobile
• Much improved real-time monitoring systems for running jobs
  • Show live CPU/memory as a timeseries chart
  • Show complete process tree with full parent/child relationships
  • Option to kill all processes on job abort.
• Proper international date/time support
• Much better "event chaining" feature
  • Allow users to create a "decision tree" of events that fire each other off
  • Improved UI to display this event relationship
• Much better event history, with filters such as "show only errors" or "show only successes".
  • Allow users to "tag" their jobs with keywords, which are also searchable.
• Remove a bunch of dependencies
  • Instead, use native or in-house solutions.
  • Examples include removal of socket.io, replaced with native WebSockets in the client, and ws on the server.
  • Also, removal of all graph/chart libraries, replaced with native SVG / Canvas code.
  • Also, removal of the legacy moment.js, replaced with native browser/Node APIs.

Anything else you'd like to see? I'm all ears!

[JTF4]

One big feature that I would love to see if a group schedule. It would be fantastic to create a group that runs at X time and all of the actions have time offsets in them that are set from the trigger time on the master group. I use cronicle for a lot of one off events and it's a lot of work to go through 30 different actions and change the time on them all, and this feature would make it so that I just have to change one time for the entire group of actions.

[jhuckaby]

@JTF4 Awesome! I love it! This fits right in with my redesign of the event chaining feature, where you can now define entire "event groups" and run jobs within that group. I will come up with a way to do this with time offsets like you said, in addition to chaining. Thank you! 🙏🏻

[justinmdudley]

This all sounds amazing. I would love to add one suggestion around users. It would be fantastic if we could utilize other identity providers using OAuth. I absolutely love Cronicle, but it is the only application we run which requires a username/password.

[jhuckaby]

@justinmdudley Ah, thank you! I forgot to list that I am adding Active Directory login support, and I will definitely work on OAuth as well.

[josephdadams]

What changes/improvements were you thinking regarding the use of plugins?

[jhuckaby]

@josephdadams Ah, I have some fun changes in store for Plugins. They will still work as they do now (launch child process and communicate with NDJSON over STDIO), but you will now be able to send back real-time telemetry about running jobs. For example, you can send back a full HTML snippet to display in real-time on the job status screen while the job is running. This is great for long-running jobs that need more detailed real-time status, more than simply "progress" and a "log".

There's more. I'm planning on a way for Plugins to submit entire files to the Cronicle master host, as a form of "output" which can be sent during or at the end of a job. These files will be downloadable from the UI, links included in the notification e-mail, can be sent as web hooks to URLs of your choice, and can even be passed between jobs by way of chaining.

Cool, right?

[JTF4]

Are you keeping with the python plugin form?

[jhuckaby]

@JTF4 I'm sorry, I am having trouble understanding. What is a "python plugin form"? Cronicle and Orchestra are both language-agnostic. They don't care what language your Plugins are written in, as long as they can read JSON via STDIN and send it via STDOUT. Python should work fine.

[josephdadams]

@JTF4 we wrote most of our plugins in Python because it was fast and easy

[ericma15]

@josephdadams啊，我为插件准备了一些有趣的变化。它们仍将像现在一样工作（启动子进程并通过 STDIO与NDJSON通信），但您现在可以发回有关正在运行的作业的实时遥测数据。例如，您可以发回完整的 HTML 片段，以便在作业运行时实时显示在作业状态屏幕上。这对于需要更详细的实时状态而不仅仅是“进度”和“日志”的长时间运行的作业来说非常有用。

还有更多。我正计划让插件将整个文件提交给 Cronicle 主控主机，作为一种“输出”形式，可以在作业期间或结束时发送。这些文件可以从 UI 下载，通知电子邮件中包含的链接，可以作为 Web 挂钩发送到您选择的 URL，甚至可以通过链接的方式在作业之间传递。

酷，对吧？

Wow, that sounds so cool!

[arivictor]

Hi @jhuckaby did you have any thoughts on secrets or credential management? If you're familiar with Jenkins, for example, it has a global credential store where users can enter usernames/passwords, secrets, keys, etc, that can then be referenced in pipelines.

We bashed out a proof of concept into Cronicle to allow users to add secrets within events which can then be passed into the plugin at job runtime, its not very robust however, but does the trick. Its not shown in the screenshot, but after entering the secret and saving the event it then encrypts it. When the job runs it gets decrypted. We've also opted to follow your syntax eg. [/secret/credential]

[mikeTWC1984]

@arivictor I agree, some sort of secret management would be extremely useful. @jhuckaby if you don't have much time to implement your own solution you can create integration with some existing tool, like hashicorp vault.

[jhuckaby]

@arivictor @mikeTWC1984 Yes this is an excellent suggestion -- thank you! I'll look into the best way to implement this, including Hashicorp Vault, of which I'm currently unfamiliar.

[care2DavidDPD]

@jhuckaby - I see that you remove the disclaimer about maintenance-only mode and Orchestra - c2bfdc1 - did plans change ?

We are going to deploy a dcron system shortly, Cronicle really fits the bill (most others are too big and complex) and can't wait for Orchestra. Just don't want to deploy something new that is DOA.

[jhuckaby]

@care2DavidDPD I apologize for the confusion -- the disclaimer is still active, it was just moved to the pull request template (actually, it was always there). I removed it from the README as it was a redundant copy, and I wanted to emphasize the latest upgrade notice about v0.8 to v0.9. Nothing has changed -- Cronicle is still being maintained, and I am working on Orchestra every free moment I have 😊

[falldeaf]

Hi @jhuckaby I just found Cronicle and started digging in, I really love the functionality. I just had a few questions if I could about Orchestra if I could.

I love the feature upgrades that you've mentioned so it sounds like I'll be happy to migrate when it's out (especially if there's automatic data migration. I was thinking it'd be neat to write a little node library you could call from your plugin code that handles communication with cronicle/orchestra. Not that the stdin and json is overly difficult but it'd be neat to have really simple promise-based commands to capture input and send info.

Since you'd said you might be interested in hearing feature ideas for Orchestra, one feature I would really love is the ability to write and test plugins right in the web interface! I'd love to be able to select 'create new plugin', in addition to the 'add new plugin', that would go to an in-browser code editor. with a run button that tests the plugin and captures the output as the system really would. Then be able to save it, and edit your plugins without logging into the server.

Lastly, this is probably not something you'd want to think about for an initial launch, but a public plugin library would be really great, too. If developers could publish plugins somewhere, and users could look though and add them, it could save devs time and make Orchestra a low/no code solution for automation as well!

Thanks! (And sorry for the wall of text, I'm excited about finding your software and hearing about a big upgrade on the horizon)

edit:(removed stupid question already answered elsewhere)

[jhuckaby]

Hi there, @falldeaf! Sorry for the late reply. Been super busy over here.

I was thinking it'd be neat to write a little node library you could call from your plugin code that handles communication with cronicle/orchestra.

Feel free! Although, I should tell you, I actually already wrote one years ago: pixl-json-stream. This is what the Shell Plugin uses to communicate with Cronicle, but I use it in a bunch of other places as well. It's not promise-based, but rather event based. It has served me very well over the years, but I'm sure it could be improved upon.

one feature I would really love is the ability to write and test plugins right in the web interface! I'd love to be able to select 'create new plugin', in addition to the 'add new plugin', that would go to an in-browser code editor.

This is a cool idea, but one problem I see with it is that Plugins often require dependencies to be installed. They also aren't always one single file, but rather many files across multiple directories. I feel like, to implement this kind of thing properly, you'd need a complete file and directory management system with a remote file editor, and the ability to install dependencies, that would need to support multiple programming languages. It kinda feels like that's a bit out of scope for Orchestra.

with a run button that tests the plugin and captures the output as the system really would. Then be able to save it, and edit your plugins without logging into the server.

I do like the idea of "testing" a Plugin, without having to create an event in the schedule. I'll definitely think about implementing this.

a public plugin library would be really great, too. If developers could publish plugins somewhere, and users could look though and add them, it could save devs time and make Orchestra a low/no code solution for automation as well!

Interesting idea. What sort of Plugins would be useful in a public library? I mean, like, what kinds of things would they do? In my own experience my Plugins have been very specialized, and wouldn't be useful to anyone else.

Semi-related to this: I was actually already thinking about opening up the "hook" system to the idea of Plugins. For example, right now Cronicle (and Orchestra) can send out web hooks for events like job completions, but people probably would love some common 3rd party actions like: post message to slack or discord, send SMS via Twilio, send push notification via Pushover, etc. Those kinds of things could be made into "Hook Plugins" or "Action Plugins" and distributed publicly, probably via NPM. I could see that kind of thing becoming a public library.

Anyway, thank you very much for the suggestions!

[solemnwarning]

Hi @jhuckaby,

I sent you an email a little while ago inquiring about the state of Cronicle v2/Orchestra before finding this discussion and #768, which answer my questions, so don't worry too much about replying to that email :)

I'm still experimenting with Cronicle and how exactly I would like to deploy it, but features I would like to see are:

• Parsing (or at least stripping) of terminal escapes/ANSI colour codes.
• Ability to run remote workers on demand over SSH, rather than requiring a full maintained/exposed Cronicle instance on the remote server. I'm currently just running the ssh commands in the job on the master node, downsides of this are the memory/etc tracking is inaccurate and the master node has to has SSH keys set up to communicate with the workers.
• Ability to start remote workers on demand via custom commands; I have a cluster of machines which shut down when idle and it would be nice if Cronicle/Orchestra could boot them when a job is queued. For the time being, I think I could accomplish this by splitting jobs into a "boot the server for job x" which runs on the master node and then triggers "actually job x". A chain reaction for running another task before the relevant one would also be a way to solve this.

[jhuckaby]

Hey @solemnwarning,

I'm glad #768 was able to answer your questions. Addressing your three feature requests here:

1. Implemented in v2! It actually parses and displays them.
2. This is solved in v2 by shipping a very small and light "satellite" binary, which you run on all your workers, instead of the full master codebase. The satellite has zero dependencies, and runs on just about everything out of the box (Linux x64/arm, macOS x64/arm, Windows x64).
3. This can be solved in v2 using a "workflow", which is a series of connected jobs. You can define reusable events with custom user parameters (e.g. "Boot Machine" and have a text field or drop-down menu to select which machine) and insert that into a workflow to run before your actual job runs.

Hope this helps! Can I ping you when v2 is released later this year? I'm starting to put together a list of all the people and places I need to ping when the thing finally comes out 😝

[solemnwarning]

If you'd like me to beta test v2 when its ready, please feel free! FWIW, I'm in the process of setting up my installation on a FreeBSD host now.

wrt. the "satellite" binary, will this involve SSH or another secure tunnel between the machines, or is it still just a HTTP service like the current mechanism?

[jhuckaby]

The Satellite communicates via WebSockets over HTTPS, but the important change in v2 is the direction: it is reversed. The new Satellite binaries do NOT open any socket listeners, nor do they need any incoming ports opened or mapped. The Satellites connect to the master now (one single persistent WebSocket connection), which makes the whole thing much easier for complex network topologies, and for running Satellite on back-end servers that have no open incoming ports.

[BenKentzer]

@jhuckaby Any news on a date for Orchestra? I'm happy to push it into our dev environment to support any final testing from your side. Looking forward to seeing how you can improve on Cronicle! We love it here :-)

Thanks

Ben

[jhuckaby]

Hi there, Ben! Thank you for the interest! It's coming along very nicely! I'm still on track for release at the end of this year (2025). I'll definitely have a beta version ready before then. Sometime in November I think? I'll definitely update this discussion when it's ready!

I'm also working on a marketing website, and a dev blog, so I can post updates on how things are going. Those should be ready at the end of this month (September), and I'll send out links when they are live.

By the way, I had to change the name. "Orchestra" is unfortunately trademarked in the US, and so I cannot use it. After a very long search, I finally arrived at... xyOps

What do you think? I really like it 😊

Pronounced "ZIE-OPS".

[BenKentzer]

Hello!

That sounds great - we've been using Cronicle for a lot of years now - still installing new worker nodes as we expand...

Looking forward to November!

Thanks

Ben

[pradip-allwyn]

what is the latest info? @jhuckaby

[jhuckaby]

@pradip-allwyn I'm still on track for release later this year! I am targeting late December 2025. I am currently working on the "coming soon" marketing site, and a dev blog for more frequent updates. The app itself is coming along great. Most major features are complete at this point. I am still working on accessibility, a configuration editor, a log viewer, configurable hot keys, and a few more things. I also still need to finish unit tests and docs.

I'm SO CLOSE! 😃 😃 😃

[dheise-rheinenergie-trading-com]

Really nice new logo! But it will be a difficult time after more than six years with Cronicle. 😥 The name is now very well known in our company and synonymous with “everything is running smoothly.” 💪🚀

[jhuckaby]

Yeah, sorry for the new product name, but it does SO much more than Cronicle did. It now does full server monitoring, custom alerts, workflow automation, ticketing, secrets management, you name it. It's more of a full "Ops toolkit" now.

That being said, it CAN be rebranded back to Cronicle if you want. I have a configuration switch to do just that. It also has full backward support for Cronicle style events, jobs, and plugins, and a migration script to bring over all your Cronicle stuff to xyOps.

[dheise-rheinenergie-trading-com]

You really think of everything. Amazing! 💪

[jhuckaby]

Happy 2026! 🎉

As promised, here is the beta of xyOps (Cronicle v2) ready for testing:

https://github.com/pixlcore/xyops

Blog post with more info:

https://pixlcore.com/blog/dev-update-2026-01

Let me know what you think!

❤️