Deployment

MultipleUpload is a static JavaScript bundle plus whatever backend you already run — deployment is mostly about putting three files in the right place.

1. Ship the runtime

From the download package's dist/ folder:

dist/multipleupload.js      // the runtime (obfuscated production build)
dist/multipleupload.css     // default styles
dist/multipleupload.d.ts    // TypeScript definitions (dev-time only)

Serve them like any static asset — your web server, your bundler's static pipeline, or your CDN. There are no runtime dependencies to install alongside.

2. Place the licence

localhost, 127.0.0.1 and ::1 never need a licence — develop freely. For production domains, deploy multipleupload.lic alongside the runtime so it resolves at ./multipleupload.lic relative to the script.

The path is derived from wherever multipleupload.js was loaded from, so the two files move together. If you need them apart — a CDN-hosted runtime with the licence on your own origin, say — set the URL before the script tag:

<script>window.__MULTIPLEUPLOAD_LICENSE_URL__ = '/licences/multipleupload.lic';</script>
<script src="https://cdn.example.com/multipleupload.js"></script>

You can also skip the request entirely by handing the licence over inline, which is worth doing if you would rather not serve an extra file at all:

<script>window.__MULTIPLEUPLOAD_LICENSE__ = { /* contents of multipleupload.lic */ };</script>
<script src="/js/multipleupload.js"></script>

Serving .lic: the one that catches people

Most static-file servers refuse to serve extensions they have no content type for, so the licence 404s even though the file is sitting in the right directory. The symptom is MultipleUpload license load skipped in the browser console. Register the extension:

// ASP.NET Core - Program.cs
var provider = new FileExtensionContentTypeProvider();
provider.Mappings[".lic"] = "application/octet-stream";
app.UseStaticFiles(new StaticFileOptions { ContentTypeProvider = provider });

# nginx
location ~ \.lic$ { default_type application/octet-stream; }

<!-- IIS - web.config -->
<staticContent><mimeMap fileExtension=".lic" mimeType="application/octet-stream" /></staticContent>

Express and most bundler dev servers serve unknown extensions already and need nothing.

3. Point it at your backend

new MultipleUpload('#uploader', {
  uploadUrl: '/api/upload',        // your endpoint
  chunked: true,
  chunkSize: 5 * 1024 * 1024
});

The backends section has reference implementations — including the Node middleware shipped in the npm package (multipleupload/server) with single, chunked and chunk-status routes.

Pre-launch checklist

Body-size limits. Your server/proxy must accept at least one chunk (chunkSize + form overhead), not the whole file.
Temp storage. Chunk staging needs writable disk and a cleanup job for abandoned sessions.
HTTPS. Required for webcam/screen capture, and for crypto APIs used by hashing and encryption-at-rest.
Server-side validation. Client checks are UX; enforce size/type limits again at the endpoint.
Resume verification. If you enable persistState, implement the chunk-status route so resumes reconcile with the server. Demo.
CORS. Cross-origin API or direct-to-cloud bucket? Allow your origin, methods, headers — and expose ETag for S3 multipart.

Download Getting started