Network permissions in Upferry: database access without internet access
A service that reads from PostgreSQL does not always need to contact the rest of the internet. An internal tool, a staging app or a scheduled job may need just one connection: to its own database.
Upferry now lets you express that requirement in service settings. Enable Restricted mode, select a service and its TCP port, then deploy. New outbound connections are blocked except for the internal connections you allow.
postgres:5432✓ AllowedInternet× BlockedGive a service the connections it needs
Consider a web app with PostgreSQL. You want the app to serve visitors and read its database, but it has no reason to call an external API. An explicit network policy makes that intent enforceable outside the application code.
In this example, you allow postgres:5432. Another port, an unselected service, a service in another environment and a public internet address remain unavailable. Use the internal service name, such as postgres or postgres.upferry.internal, for the allowed connection.
Enable it in Settings
Open the service in Upferry and go to Settings → Network permissions.
- Select Restricted mode.
- Choose the internal service and TCP ports it may reach. For PostgreSQL, that is usually postgres on port 5432.
- Save and deploy. The form can deploy the selected environment immediately after saving.
An empty allowlist blocks all new outbound connections. Existing services keep Open mode until you explicitly change and deploy their policy.
Saved does not mean active
The panel shows the saved setting separately from the policy of the running deployment. Saving without deploying leaves that deployment unchanged. If the replacement fails, the previous version keeps running with its previous policy.
The setting belongs to the service across its environments. Deploy each running environment to apply a change there. Permissions only reach the selected service in the same environment.
If you need restrictions from the first execution of your code, set the policy before deploying it. Creating a service with automatic deployment starts that first deployment in Open mode.
The same rules for jobs and rollbacks
Pre-deploy commands use the same network policy as the application. A database migration can reach the database you allow without gaining a separate route to the internet.
Cron reads the current owner setting before each new run. A job already in progress keeps its previous policy. Rolling back an image keeps the current network permissions from the panel, so an older image does not restore an older, more permissive policy.
Permissions follow the selected service identity rather than a recyclable name. Recreating a different service under the old name does not transfer access.
Check your external dependencies first
Restricted mode also blocks external APIs, email providers and public DNS. An app that calls a payment API, Resend or Telegram needs those connections and will not work unchanged in this mode. Public domain allowlists are not part of this release.
This release controls application runtime, cron and pre-deploy commands. Dependency installation and image builds retain their normal network access. Allowed connections are internal TCP connections; outbound UDP and IPv6 are blocked.
This is one layer of protection. An allowed service can forward data, and an application can put sensitive data in a reply to an incoming web request. Network permissions do not prevent those actions or protect against a compromised host.
See recent blocked destinations
The same Settings section shows sampled destination addresses, ports, packet counts and an approximate last-seen time. It records neither request contents nor credentials.
These are bounded samples, not a complete connection audit. Entries expire after ten minutes without a recorded packet, and an empty list does not prove that no traffic was blocked.
Available now
Network permissions are enabled on our production installation. Before release, we tested Linux on amd64, PostgreSQL access, blocked DNS paths, Docker restart recovery, cron and pre-deploy execution. We also verified the full service flow through the production API and HTTPS routing, including rollback and cleanup.
Start with a service whose required connections you know. Allow only the internal services and ports it needs, deploy, and check that the application still behaves as expected.