Build an Image Upload and Optimization Pipeline with DigitalOcean

This guide builds a deliberately small production-shaped pipeline. The browser never receives a Spaces secret. It asks your App Platform app for a short-lived upload URL, sends the original directly to a private object key, then asks the app to start a secured Function. The Function reads the original, writes 400, 800, and 1600 pixel WebP variants, and returns CDN URLs.

Use it for profile photos, listings, portfolio images, or another modest synchronous workload. It is not a substitute for an account system, malware scanning, or a durable queue. The starter limits uploads to JPEG, PNG, and WebP at 10 MB; add authentication and quotas before accepting untrusted traffic at scale.

The important boundary is direct-to-storage upload. Sending a full image through an API route wastes application bandwidth and risks request-size limits. Instead, POST metadata to /api/uploads, receive a five-minute presigned PUT URL, and upload directly to Spaces. The response includes an unguessable UUID, not the original filename, so object keys do not disclose user input.

After the PUT succeeds, the browser POSTs that UUID to the same-origin /api/images/:id/process route. That route invokes the Function with its web-auth secret. The Function URL and its X-Require-Whisk-Auth value never reach the browser. Image bytes move only between browser, Spaces, and Function.

Create a standard Spaces bucket in the same region as the app. Enable its CDN. Keep file listing disabled. The application writes originals with the private ACL and writes only generated files with the public-read ACL. This gives you one billable store and a simple prefix convention without accidentally exposing the upload path.

Configure the Space’s CORS rule to allow PUT from your deployed App Platform origin only. Allow the PUT method and Content-Type header. Do not use a wildcard origin in production. The exact console screens can evolve, so keep the starter’s README as the source of truth for the values you enter.

Clone the companion starter from examples/digitalocean-image-upload-pipeline, copy .env.example to .env.local, and fill in your Space, region, access key, secret, CDN base URL, Function URL, and a long random Function secret. The access keys live only in App Platform encrypted runtime variables and the Function component configuration; do not prefix them with NEXT_PUBLIC_.

The Function project.yml marks the action as web-accessible but requires the same secret through X-Require-Whisk-Auth. App Platform supports encrypted runtime variables, and Functions can template component variables from project.yml. Give Sharp a remote build: native dependencies must be compiled for the Functions runtime, not your laptop.

Push the starter repository to GitHub, then create an App Platform app from the repository. The .do/app.yaml file declares the Next.js service and the Functions component. Add the values from .env.example as encrypted runtime variables in the control panel before deploying. Do not put secrets in the repository or app spec.

Deploy the Function with the remote-build command from its directory. The app service needs FUNCTION_URL and FUNCTION_AUTH_TOKEN to call it; the Function needs the Spaces variables. Use the URL shown for the deployed Function in App Platform settings. Then update FUNCTION_URL in the app service and redeploy once.

Open the deployed app, choose a JPEG, PNG, or WebP no larger than 10 MB, and upload it. The page first reports that the original reached Spaces, then requests processing and renders the returned variant URLs. Inspect the bucket: uploads/<uuid>/original must remain private, while images/<uuid>/400.webp, 800.webp, and 1600.webp are the only public objects.

Open one returned CDN URL in a private browser window. It should load without a signed query string. If it does not, check the object ACL first, then the CDN endpoint and cache propagation. Do not test access by making uploads/ public; that defeats the design.

The Function receives a tiny JSON object containing an asset ID; it never receives image bytes. Even so, processing is synchronous. DigitalOcean Functions have configurable memory and timeout limits, a 48 MB built-function limit, and a 1 MB request/response limit. Set memory and timeout high enough for your largest permitted image, then reject inputs that do not fit the tested envelope.

For long-running transformations, high upload volume, video, or retryable work, use a queue and worker pattern instead. Add content verification, rate limiting, authorization, lifecycle deletion, and antivirus scanning before you treat this starter as a user-generated-content service. If variants must be private, replace public CDN URLs with an authorized delivery design; presigned CDN URLs do not receive normal CDN cache benefits.