How to Set Up IronPdfEngine
IronPdfEngine is a gRPC server that performs every PDF operation — creating, editing, reading, and rendering. The IronPDF for Java library is an API wrapper around this server: when your Java code calls any IronPDF method, IronPdfEngine executes the work. By default, IronPDF for Java spawns IronPdfEngine as a local subprocess and manages its lifecycle automatically. For more advanced deployments — shared microservices, Docker containers, or air-gapped networks — you can run IronPdfEngine as a standalone remote server instead.
Quickstart: Set Up IronPdfEngine for Java
How to Set Up IronPdfEngine for Java
- Add the IronPDF dependency to your
pom.xmlfile - Choose a local mode: runtime download or bundled dependency
- For remote mode, use
setIronPdfEngineHostto configure the host address - For remote mode, use
setIronPdfEnginePortto configure the port - Call any IronPDF rendering method — IronPdfEngine handles the PDF work
Settings.getIronPdfEngineVersion() to confirm the required version.Which Deployment Mode Should You Use?
IronPdfEngine supports two deployment approaches: local and remote. Choosing between them depends on the architecture of your application.
Local mode (the default) is the right choice for standalone applications, desktop tools, and single-server deployments. IronPDF for Java starts IronPdfEngine automatically as a subprocess — no separate infrastructure is needed. Within local mode there are two options for obtaining the IronPdfEngine binaries: download them at first run or bundle them as a Maven dependency.
Remote mode fits distributed systems where a single IronPdfEngine instance serves multiple application nodes. It is also the preferred approach for Docker-based deployments, Kubernetes pods, air-gapped networks that cannot download binaries at runtime, and any scenario where centralizing PDF processing reduces per-service overhead.
The sections below cover both modes in detail.
How Do You Set Up Local IronPdfEngine?
Two options exist for running IronPdfEngine locally. Both produce the same runtime behavior — the difference is when and how the engine binary arrives on the target machine.
Option 1: Download IronPdfEngine at Runtime
By default, after adding the core ironpdf dependency, IronPDF detects the host platform (for example, Windows x64 or Linux x64) on the first run and downloads the matching IronPdfEngine binary from the internet.
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf</artifactId>
<version>20xx.xx.xx</version>
</dependency>
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf</artifactId>
<version>20xx.xx.xx</version>
</dependency>
After the initial download, the binary is cached locally and subsequent runs start without a network call.
| Advantage | Limitation |
|---|---|
| Smallest application package size | Internet access required on first run |
| Supports multiple target platforms from one artifact | Slower first-run startup while binary downloads |
Option 2: Bundle IronPdfEngine as a Dependency (Recommended)
IronPDF Java provides platform-specific Maven artifacts that bundle IronPdfEngine as a .zip file inside the dependency. The library extracts and uses it automatically — no network call is needed at runtime.
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
Then add the platform artifact for your target environment. Install only the artifact for your target platform — each one is large, and installing all of them unnecessarily inflates the build.
Windows x64
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-windows-x64</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-windows-x64</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
Windows x86
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-windows-x86</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-windows-x86</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
Linux x64
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-linux-x64</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-linux-x64</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
macOS x64
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-macos-x64</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-macos-x64</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
macOS ARM (Apple Silicon)
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-macos-arm64</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
//:path=pom.xml
<dependency>
<groupId>com.ironsoftware</groupId>
<artifactId>ironpdf-engine-macos-arm64</artifactId>
<version>20xx.xx.xxxx</version>
</dependency>
ironpdf and ironpdf-engine-xxx-xxx dependency versions must match exactly. The version string refers to the IronPDF for Java release, not IronPdfEngine's internal version number.| Advantage | Limitation |
|---|---|
| Faster startup — no download step | Larger application package |
| No internet access required after installation | Must specify target platform explicitly |
| Consistent behavior in air-gapped environments | Installing multiple platform artifacts inflates build size significantly |
How Do You Connect to a Remote IronPdfEngine?
Remote mode lets multiple application instances share a single IronPdfEngine server over gRPC. This is common in microservice architectures, containerized deployments, and environments where PDF processing is centralized.
How Do You Verify the Required IronPdfEngine Version?
Version matching is strict — IronPDF for Java 2024.2.2 requires IronPdfEngine 2024.2.2 exactly. Use getIronPdfEngineVersion to confirm the required version before deploying the server:
:path=/static-assets/ironpdf-java/content-code-examples/get-started/use-ironpdfengine-8.java
// Retrieve the IronPdfEngine version required by this Java library build
String ironPdfEngineVersion = Settings.getIronPdfEngineVersion();
System.out.println("Required IronPdfEngine version: " + ironPdfEngineVersion);
Deploy or pull the IronPdfEngine Docker image or binary that matches the returned version string.
How Do You Configure the Remote Connection?
Assume IronPdfEngine is running at 123.456.7.8:33350. Set the host and port before calling any IronPDF method. The best practice is to place these calls at application startup, before any PDF operation:
:path=/static-assets/ironpdf-java/content-code-examples/get-started/use-ironpdfengine-9.java
// Configure IronPDF for Java to connect to a remote IronPdfEngine instance
com.ironsoftware.ironpdf.Settings.setIronPdfEngineHost("123.456.7.8");
com.ironsoftware.ironpdf.Settings.setIronPdfEnginePort(33350);
After these two lines execute, all subsequent IronPDF calls in your application route to the remote server. No local IronPdfEngine subprocess is started, and no platform-specific engine dependency is needed in your pom.xml.
33350 is open in any firewalls or security groups between the two.What Does a Complete Remote Setup Look Like?
The following example connects to a remote IronPdfEngine instance and renders an HTML string to a PDF file — the same API used in local mode, with only the configuration differing:
//:path=Main.java
import com.ironsoftware.ironpdf.*;
public class Main {
public static void main(String[] args) throws Exception {
// Point the library to the remote IronPdfEngine server
Settings.setIronPdfEngineHost("123.456.7.8");
Settings.setIronPdfEnginePort(33350);
// Render HTML to PDF — IronPdfEngine on the remote host performs the work
PdfDocument pdf = PdfDocument.renderHtmlAsPdf("<h1>Hello from remote IronPdfEngine</h1>");
pdf.saveAs("output.pdf");
}
}
//:path=Main.java
import com.ironsoftware.ironpdf.*;
public class Main {
public static void main(String[] args) throws Exception {
// Point the library to the remote IronPdfEngine server
Settings.setIronPdfEngineHost("123.456.7.8");
Settings.setIronPdfEnginePort(33350);
// Render HTML to PDF — IronPdfEngine on the remote host performs the work
PdfDocument pdf = PdfDocument.renderHtmlAsPdf("<h1>Hello from remote IronPdfEngine</h1>");
pdf.saveAs("output.pdf");
}
}
The rendered PDF is returned to the Java process over gRPC and saved locally. The remote server handles all Chrome-based rendering, font loading, and resource resolution.
What Are the Next Steps?
With IronPdfEngine configured, the full IronPDF for Java feature set is available — HTML to PDF, PDF editing, merging, stamping, and more.
- Start rendering HTML to PDF in Java — step-by-step examples for the most common conversion scenarios
- Explore the IronPDF for Java tutorials — deeper guides covering watermarks, headers and footers, forms, and digital signatures
- Download IronPDF for Java and start a free trial — full-featured trial with no time limit on development use
- Purchase a license for production deployment — perpetual and subscription options with source code access
Frequently Asked Questions
What is IronPdfEngine and why does IronPDF for Java require it?
IronPdfEngine is a gRPC server that executes all PDF operations — creating, editing, reading, and rendering. IronPDF for Java is an API wrapper around this server, so every Java method call is processed by IronPdfEngine. Without it, the Java library cannot perform any PDF work.
What is the difference between local and remote IronPdfEngine?
Local mode starts IronPdfEngine as a subprocess on the same machine as your Java application — no extra infrastructure needed. Remote mode connects to a standalone IronPdfEngine server over gRPC, which is suited to microservices, Docker deployments, and shared PDF processing nodes.
When should I use remote IronPdfEngine instead of local?
Use remote IronPdfEngine when you need multiple application instances to share one PDF processing server, when deploying in Kubernetes or Docker Compose environments, or when running in air-gapped networks that cannot download binaries at runtime.
How do I configure a remote IronPdfEngine connection in Java?
Call Settings.setIronPdfEngineHost() with the server IP or hostname and Settings.setIronPdfEnginePort() with the port number at application startup, before invoking any IronPDF method. The default IronPdfEngine port is 33350.
Which Maven artifact should I use to bundle IronPdfEngine as a dependency?
Add the platform-specific artifact matching your deployment target — for example, ironpdf-engine-linux-x64 for Linux servers or ironpdf-engine-windows-x64 for Windows. The artifact version must match the ironpdf core dependency version exactly.
How do I check which IronPdfEngine version my Java library requires?
Call Settings.getIronPdfEngineVersion() in your Java code. It returns the exact version string that must match the IronPdfEngine binary or Docker image you deploy.
Can I install multiple platform engine dependencies in one project?
Technically yes, but each artifact is large and installing more than one unnecessarily inflates your build. Install only the artifact matching your target deployment platform.
Do I need an internet connection to use IronPDF for Java?
Only if you use the runtime-download option (no platform-specific dependency in pom.xml). On the first run, IronPDF downloads the IronPdfEngine binary for your platform. After that download, no internet access is required. If you add the bundled platform dependency or use remote mode, no internet access is needed at any point.


