# CustomDeploymentDirectory in AWS Lambda
When you run IronPDF in an AWS Lambda function under Docker, you may try to point `CustomDeploymentDirectory` at a writable temporary path like `/tmp`. Doing so can produce a misleading log line about a failed binary lookup, yet PDF rendering keeps working normally.
```txt
Attempting deployment for 'Pdfium' using '/tmp/'
Failed to locate assembly(s) for deployment '/tmp/' at path '/tmp/'
Successfully located 'IronPdfInterop' at '/var/task'
```
The message looks like a failure, but it is informational. IronPDF prefers assemblies that are already deployed and only consults the custom path as a fallback. In Lambda, your Docker container's working directory is usually `/var/task`, where the binaries already live, so IronPDF finds them there and proceeds.
`CustomDeploymentDirectory` serves two roles: a directory to download and deploy native components such as `IronPdf.Native.Chrome.Linux`, and an alternative lookup path for runtime dependencies that are not found in the standard locations. Because the engine favors already-deployed binaries, the `/tmp` path is unnecessary unless you depend on `IronPdf.Slim` or on runtime NuGet downloads of the native binaries.
[[i:(The fallback log lines are informational, not errors. If rendering succeeds, no action is needed.)]]
## Solution
### Option 1: Standard IronPdf.Linux deployment
For most Lambda plus Docker deployments using `IronPdf.Linux`, the simplest and most reliable setup skips the custom directory entirely:
```csharp
IronPdf.Installation.AutomaticallyDownloadNativeBinaries = false;
IronPdf.Installation.LinuxAndDockerDependenciesAutoConfig = false;
IronPdf.Installation.ChromeGpuMode = IronPdf.Engines.Chrome.ChromeGpuModes.Disabled;
IronPdf.Installation.SingleProcess = true;
```
Disabling the automatic downloads tells IronPDF the native binaries are already packaged, and `SingleProcess` keeps the engine in one process, which suits the constrained Lambda runtime.
### Option 2: IronPdf.Slim deployment
If you ship `IronPdf.Slim` with Docker, route IronPDF's temporary and deployment paths to `/tmp`, the only writable directory in Lambda:
```csharp
var awsTmpPath = @"/tmp/"; // AWS temporary storage path
// Configuration for IronPDF rendering
IronPdf.Installation.ChromeGpuMode = IronPdf.Engines.Chrome.ChromeGpuModes.Disabled;
IronPdf.Installation.DefaultRenderingEngine = IronPdf.Rendering.PdfRenderingEngine.Chrome;
Environment.SetEnvironmentVariable("TEMP", awsTmpPath, EnvironmentVariableTarget.Process);
Environment.SetEnvironmentVariable("TMP", awsTmpPath, EnvironmentVariableTarget.Process);
IronPdf.Installation.TempFolderPath = awsTmpPath;
IronPdf.Installation.CustomDeploymentDirectory = awsTmpPath;
IronPdf.Installation.LinuxAndDockerDependenciesAutoConfig = true;
```
Here `CustomDeploymentDirectory` earns its place: the Slim package downloads native components at runtime, and `/tmp` gives them a writable home. Enabling `LinuxAndDockerDependenciesAutoConfig` lets IronPDF set up the Linux dependencies on first run.
## When to Set It
- **Leave it unset when:** you package IronPDF dependencies such as `IronPdf.Linux` with your project, use full deployments without runtime downloads, and the function can reach everything from `/var/task`.
- **Set it to `/tmp` when:** you use `IronPdf.Slim` without bundled native binaries, rely on runtime NuGet downloads for components like `IronPdf.Native.Chrome.Linux`, or need temporary deployments stored in Lambda's only writable directory.
When you run IronPDF in an AWS Lambda function under Docker, you may try to point CustomDeploymentDirectory at a writable temporary path like /tmp. Doing so can produce a misleading log line about a failed binary lookup, yet PDF rendering keeps working normally.
Attempting deployment for 'Pdfium' using '/tmp/'Failed to locate assembly(s) for deployment '/tmp/' at path '/tmp/'Successfully located 'IronPdfInterop' at '/var/task'
Attempting deployment for 'Pdfium' using '/tmp/'
Failed to locate assembly(s) for deployment '/tmp/' at path '/tmp/'
Successfully located 'IronPdfInterop' at '/var/task'
Text
The message looks like a failure, but it is informational. IronPDF prefers assemblies that are already deployed and only consults the custom path as a fallback. In Lambda, your Docker container's working directory is usually /var/task, where the binaries already live, so IronPDF finds them there and proceeds.
CustomDeploymentDirectory serves two roles: a directory to download and deploy native components such as IronPdf.Native.Chrome.Linux, and an alternative lookup path for runtime dependencies that are not found in the standard locations. Because the engine favors already-deployed binaries, the /tmp path is unnecessary unless you depend on IronPdf.Slim or on runtime NuGet downloads of the native binaries.
Please note: The fallback log lines are informational, not errors. If rendering succeeds, no action is needed.
Solution
Option 1: Standard IronPdf.Linux deployment
For most Lambda plus Docker deployments using IronPdf.Linux, the simplest and most reliable setup skips the custom directory entirely:
Disabling the automatic downloads tells IronPDF the native binaries are already packaged, and SingleProcess keeps the engine in one process, which suits the constrained Lambda runtime.
Option 2: IronPdf.Slim deployment
If you ship IronPdf.Slim with Docker, route IronPDF's temporary and deployment paths to /tmp, the only writable directory in Lambda:
Here CustomDeploymentDirectory earns its place: the Slim package downloads native components at runtime, and /tmp gives them a writable home. Enabling LinuxAndDockerDependenciesAutoConfig lets IronPDF set up the Linux dependencies on first run.
When to Set It
Leave it unset when: you package IronPDF dependencies such as IronPdf.Linux with your project, use full deployments without runtime downloads, and the function can reach everything from /var/task.
Set it to /tmp when: you use IronPdf.Slim without bundled native binaries, rely on runtime NuGet downloads for components like IronPdf.Native.Chrome.Linux, or need temporary deployments stored in Lambda's only writable directory.
Curtis Chau holds a Bachelor’s degree in Computer Science (Carleton University) and specializes in front-end development with expertise in Node.js, TypeScript, JavaScript, and React. Passionate about crafting intuitive and aesthetically pleasing user interfaces, Curtis enjoys working with modern frameworks and creating well-structured, visually appealing manuals.
