#Restricting downloads by IP address

Use a download IP allowlist to distribute your app through a corporate network, VPN, or a download server with fixed public egress addresses. Requests from addresses outside the allowlist receive HTTP 403.

The policy applies to the app's ToDesktop download links, direct artifact URLs, custom download domains, update manifests, and Debian APT repository responses. It is managed through the downloadAccess API. Apps without a policy remain public. There is currently no dashboard setting for this feature.

#Prepare the app and network

1. Contact ToDesktop to configure private artifact storage for the app. Restricting CDN access only protects your files when alternate storage URLs also prevent anonymous downloads. The API returns 409 private-storage-required until the app is ready.
2. Identify the public IPv4 and IPv6 addresses used by your network or download proxy. Include every egress address that legitimate downloads may use. Local addresses on a device or server are not its public source address.
3. Prepare an access token belonging to the app owner. A personal token must be scoped to this app. Collaborators can read the policy but cannot change it.
4. Confirm how installed apps will reach update checks and downloads. They must use an allowed network or proxy too; installing from an allowed network does not grant access from other networks later.

For user-authenticated downloads, have your server authenticate the user and fetch the file from ToDesktop using an allowed egress address. Proxy the response back to the user: redirecting their browser to the CDN sends a new request from the user's address. The IP allowlist authorizes the network address, so your server remains responsible for user authentication.

The CDN uses the connecting address supplied by Cloudflare. Setting X-Forwarded-For or another client header does not grant access. Cloudflare Worker proxies can have different source-address behavior from servers with fixed egress IPs; confirm the actual address with ToDesktop before relying on one.

#Set the policy

Use the API reference to:

• Read the current policy.
• Set or replace the allowlist.
• Restore public downloads.

Each PUT supplies the complete policy. For example, adding a new network requires including the existing networks you want to retain. Once private storage is set up, allowlist changes can be made through the API without another setup step.

#Verify downloads and updates

After a successful PUT, test a download from both an allowed network and a network outside the allowlist. Repeat this for direct artifact URLs, your custom download domain if used, and the installed app's update flow. Include a file that has already been downloaded so you also exercise cached content.

An allowed address can download normally. An address outside the allowlist receives 403, even for a cached file. Successful restricted responses use Cache-Control: private, no-store; denied requests use Cache-Control: no-store. If the download service cannot load or validate the policy, it returns an error instead of granting access.

If your download links redirect to another ToDesktop app, each app in the chain is checked. Restrict every target app whose artifacts must remain private; restricting one app does not protect another app's independent download links. Redirects to external update feeds are not supported for restricted downloads.

For a 503 invalidation-failed response, follow the API's retry instructions: the policy was saved, but invalidation must be retried.

Deleting an app is also not an immediate revocation mechanism. A cached policy can continue to allow downloads until the configuration expires or is invalidated; after that, the missing app returns 404.

These restrictions control future downloads. They do not revoke copies that users have already downloaded or control access to data inside your app.