I'm Max Dunn from Silicon Publishing, and I'm here at the 2026 Creative Developers Conference, talking about InDesign Server and Adobe Firefly Services. I'm joined by my colleagues Olav Martin Kvern and Jeremiah Lynn. What is InDesign Server? I think of many of you already know it well, but for those who don't, it's simply a headless version of Adobe InDesign, which we've used for 20 years as the core rendition engine behind our software and solutions. We use it for database publishing, an example being Royal Caribbean Cruises. We automated production of their cruise booklets. We also use it for online editing solutions, helping our clients create unique white label editors that roundtrip InDesign and HTML5. Now, InDesign Server alone isn't really a server, and it's definitely not a web service. To make our solutions scale, we've worked over 20 years to master load balancing.
Job queuing and many other aspects of an infinitely scalable solution. The result is that all of our solutions runs on a layer around InDesign that we call Nucleus. Here's where Ole and Jeremiah can explain it better than me.
So, what is Nucleus really? It's our host application that manages InDesign Server as a subprocess. It's really powerful. Handles all the scaling for you. So as a client, you can come and submit your script requests to get renditions out, and you don't have to worry about load balancing or any of that. It's all managed in house. You can build very powerful products based off of that as a rendition engine. And the other things it provides is asset storage and live assets for rendition. So when you want to render a document with some images in it, those all exist on the same file system.
That gives us really fast render times.
During more than two decades deploying solutions, we've benefited enormously from our relationship with Adobe. They fully supported us as developers, treating us like true partners. Especially in the early years when InDesign was competing against QuarkXPress, third-party developers were like rock stars. I remember in 2006, Adobe flying us to San Jose, putting us up at the Fairmont. And treating us to three days of sessions where they shared their roadmaps and let me meet the CTO and CEO. Silicon Publishing wouldn't have this level without the amazing developer support and solution partnership that they provided in that era. As InDesign eclipsed Quark, that level of third-party engagement naturally diminished, an understandable shift in priorities. But I'd argue that third-party ecosystems remain valuable for any software product, and this was certainly a large part of how InDesign.
Came to be the tool of choice for creating print documents. So we've spoken about InDesign Server and Nucleus. What is Firefly Services? Firefly Services is something we spent decades urging Adobe to create. Today they offer their very best applications such as Photoshop, Premiere Pro, Lightroom, Illustrator, and InDesign as web services in conjunction with their amazing AI product Firefly. Let's have Ole and Jeremiah talk about the differences between Nucleus.
And Adobe Firefly services.
So the primary difference between InDesign Server on Nucleus and InDesign Server on Firefly it's a different strategy for content management. It's a different strategy for load balancing. So Nucleus we scale almost ahead of time. We're ready to accept jobs at any moment. But Firefly services they have more of an elastic strategy, where as you send more and more jobs. It'll spin up and more servers, slowly but surely. And so, InDesign Server on Firefly Services is more positioned to handle really wide bandwidth, but not necessarily super fast renditions. Nucleus is tuned to handle really fast renditions, and it can be configured to have high bandwidth as well. But that's generally the leaning of both both solutions. Firefly Services is also meant to be stateless, so anything coming into a job and coming out.
It is expected to be all one shot. Submit all your assets as pre-signed URLs, and you get pre-signed URLs out to download your outputs. Versus Nucleus has an idea of state where you can have templates, you have content ready to be rendered on the server, and then your downloads are all persisted on the server for some amount of time. That's all configurable in Nucleus, but it can exist on the server for much longer.
How would you characterize the difference in scaling between the two? You mentioned that earlier, but let's go back to it for a second.
Yeah, so a lot of the clients that are on Nucleus are high-performance, quick jobs. We do a lot of long renders too. We're actually we're kind of tuned for both, where we can handle massive, long - running jobs. We have certain large organizations who will run hundred - page jobs, and so that'll be hours long, just because there's so many pages, so much content to be rendered. We also have clients who need sub-second renders. Firefly services isn't really tuned for either of those. Handles a lot of middle-tier jobs, anything in your like 10 to 60 second range, the scaling performance is really set up so that as you have more of those 10 to 60 second jobs, again, it'll spin up a couple more servers up to a set maximum that probably depends on your client account. But so it's really.
It's tuned for a very specific set of jobs. Nucleus has a lot of flexibility. We can tune for really quick renders, and we can tune for really long jobs.
But what about the Adobe Firefly Services ecosystem? We have some history here. In 2018, we went to Adobe Noida to help create the InDesign API that's now part of Firefly Services. We also collaborated on the Photoshop API in its infancy. When I heard in 2022 that these products were finally going to market, I thought, great, we can build on top of this instead of Nucleus. What I hadn't anticipated was this: the initial go-to-market strategy did not include a role for third-party developers. For a time, we didn't even have access to the very APIs we'd helped create. I understand that there were good reasons to launch in a controlled way, but as someone who's seen what the third-party ecosystem did for InDesign, I think it was a missed opportunity. The good news is that in 2025, this came back around.
And we've been working on a consulting basis to help with Firefly Services solutions, now for over a year. Many at Adobe have told us that third parties will be engaged more broadly over time. So far, we're the only third party working with this technology, and we'd like to see that number grow because that's how ecosystems get built. Anubhav Rohatgi, Adobe's senior director of product management, will be speaking later, and I'm looking forward to hearing where things are headed. I'd also like to talk about what we're working on currently.
Ole and Jeremiah can explain a couple new things we have in motion, starting with Jeremiah's work on the deployment of our products to both Nucleus and Adobe Firefly services.
So you've been working on something you're calling the InDesign Script Manager, and as I understand it, that should mean that you can run the same script in Nucleus in Firefly Services. Tell us more about that.
So the InDesign Script Manager, it's essentially a wrapper. Since both Firefly Services and Nucleus are just running InDesign Server under the hood, you can basically run the exact same logic. Either environment makes no difference. The main difference is the input and the output. So if we can manage the input and the output, we can write a script, and we could send that same script to both, and you just need something that will map your input and your output for both environments. And the magic kind of comes in a little bit because we also have a lot of support for things on Nucleus like templates, fonts, content that don't yet exist in Firefly since it's stateless. And so a lot of that ends up being mocked through AWS or Azure or bring your own storage solution, right?
Whatever the customer has.
Yeah, we can mock it through that, and then you can manage all your content almost as if it was existing persisted assets on Nucleus. But they're now existing persist on AWS, and at runtime we can pre-sign those assets and send that to the script for Firefly. So you write the same script, run it on Firefly, you can run it on Nucleus, and lately I've been building up the support to compile all that and run it on your desktop as well for clients who want to run things locally or just get a quick rendition in.
Really, debugging on the desktop is the way to go. This is this is what's great where you have InDesign script. Will run on either InDesign Server or InDesign Desktop with very few changes. So I've always told people develop on the desktop, deploy to the server.
And for me, for local development, I have my own InDesign Server running. Right. So I actually I'll sometimes run in InDesign Desktop, I'll sometimes run in InDesign Server locally, and then the Script Manager itself has a whole very powerful harness at this point built in, so I can actually define a job that uses assets on Nucleus. And I can run that locally, and it's smart enough to know that hey, these servers, these assets exist on the server. I need to cache them before I run my local debug. And so you can you can really play. It's the whole world is your oyster.
I have a local InDesign server debugging set up, but it's a command line. It's nothing sophisticated.
Another focus is strong typing, which has already been dealt with at this conference by Vlad and others. Here are some thoughts about it from Ole and Jeremiah's perspective. This is the final part of our presentation.
Extendscript is JavaScript. It's an old version of JavaScript, ES3, with a lot of extra features.
Some ES5.
Features crept in.
Yeah. But essentially, it's still JavaScript. In the world that we live in now, with web and all of the web advancements, we have a ton of tooling built around JavaScript. TypeScript really is just a tool built with a type header file that allows a consumer of said code to know what each function does and to have some reasonable assurances around functionality. And so I inherited a lot of wealth when I came into this company. We have a lot of ExtendScript projects.
Years of information, years of people who have been doing this for many years, have a lot of knowledge and experience. But one thing I found was lacking was, as a developer who didn't have that, who didn't have all the DOM experience in the world, who wasn't there to see these things formed, I would look at code and I'd have no idea what was handwritten one-off functions, what was copy-pasted from a different place. I had no reasonable assurance about. What does a DOM method actually do? Okay, you have a DOM method add item on some other collection object, but I have no idea where that collection came from. And then once you start getting that in functions, now you really have no idea. It says reasonable, but what if somebody passed it something else? You have no way to have no contract to hold. So I've been going back and trying to clean up a lot of it for the.
Future of development, not necessarily for those who already know these things really well, but to create types for the whole DOM. There's actually an open source community project that had some type bindings for InDesign and all the other Creative Cloud apps, and I've forked that and I have been updating the type specifics for InDesign whenever I find something that's wrong or things like the properties object. Right. Being able to use that as a getter and setter, that's a handful of improvements that I've been adding just slowly over the last number of years, and that's for the DOM specifically, so, okay, this is a document. I know what operations I can use on a file if I'm using that in the document. I don't have to go pull up my DOM reference guidebook and look and flip through the pages and try to find.
Actual functions.
Auto complete is something you get with this, which is a great thing.
Yeah. The other thing that I'm trying to implement is adding those type definitions for our JavaScript files. So again, TypeScript, you normally write a code in TypeScript, a file in TypeScript, and you compile that to JavaScript in a type header file. But as a consumer, all that matters is that there is a JavaScript file and a type header file. So we can actually write ExtendScript, just normal ExtendScript, and you can provide a header file as well that has all the types manually written, or there are ways to auto-generate those. And that way we can write real library code with type support, and we can have consumers use that that library code. In essence, though, the JavaScript you're writing is still just JavaScript. So it's still the code you write is still loosely typed.
But you write up the definition. You'd write up the contract that gives type support later. Right. So that's one big change I've been working on implementing, kind of across a lot of our ExtendScript related projects.
You're doing things that we've all wanted to do for years. It's just we really haven't had the time to step back and build that architecture. It's always been okay. What's on fire next? It's great to have someone come in and do that, and really huge improvements in the future.