Build an image upload and optimization pipeline

This starter uploads a private original and creates public WebP variants. 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.

For the first check, use an image at least 1600 pixels wide after orientation, under 10 MB. The processor does not upscale: smaller originals can produce differently named files with the same physical width. Inspect the output dimensions as well as the three URLs.

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 and inspect .env.example to prepare the encrypted deployment variables. The local server below is optional. To test processing locally, first deploy the Function in the next section, then copy its URL and the other values into .env.local. 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. App Platform builds Sharp for the Functions runtime during deployment.

Use App Platform to deploy both components from GitHub. This path works in the browser and does not require doctl. App Platform builds the Functions component remotely, including Sharp's native dependencies.

The web service and Function both need SPACES_BUCKET, SPACES_REGION, SPACES_KEY, SPACES_SECRET, and SPACES_CDN_BASE_URL. Set the same long FUNCTION_AUTH_TOKEN in both components. Only the web service needs FUNCTION_URL. Keep these values in encrypted dashboard variables.

Companion revision 5b8eafa contains the web service and the Functions action with index.js and its dependencies in functions/packages/image/process/. Check that structure in your copy before deployment. Build and image-processing tests pass; deployment with your credentials still needs verification.

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.