# Ensure internal applications are not deployed as public web services

- Source: https://support.icompaas.com/support/solutions/articles/a_1793876663544564-ensure-internal-applications-are-not-deployed-as-public-web-services
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Render Cloud](https://support.icompaas.com/support/solutions/c_1793875953948152) › [Checks](https://support.icompaas.com/support/solutions/folders/f_1793875960840493)
- Last updated: 2026-11-05
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure applications that are meant only for internal use, such as admin panels, internal APIs, and dashboards, are deployed as private services, which have no public URL, or are protected with inbound IP rules that allow only trusted IP ranges.

**Rationale**

Every Render web service gets a public onrender.com URL that anyone on the internet can reach. Internal tools exposed this way are often less hardened and become easy targets for attackers. Running them as private services, or restricting access to known IPs, keeps them off the public internet.

**Impact**

-   Internal tools are not reachable from the public internet
    
-   Reduces the attack surface
    
-   Users must connect through the private network, a VPN, or an allowed IP
    

**Default Value**

Web services are publicly reachable at their onrender.com subdomain by default. Inbound IP rules for services require a Scale or Enterprise plan.

**Pre-Requisites**

-   Admin or Developer role
    
-   A list of internal-only applications
    
-   Scale or Enterprise plan for inbound IP rules
    

**Remediation**

**Test Plan**

1.  Sign in to the Render Dashboard at [https://dashboard.render.com](https://dashboard.render.com/).
    
2.  Review the web services in your workspace and identify any that are internal-only.
    
3.  For each one, open the service's Settings page and check whether inbound IP rules restrict access to trusted ranges.
    
4.  If an internal app is a public web service with no IP restriction, follow the implementation steps.
    

**Implementation Steps**

1.  Option 1: Create the application as a private service (New > Private Service) with the same repository and settings, move traffic to it over the private network, then delete the public web service.
    
2.  Option 2 (Scale or Enterprise): open the web service's Settings page, add inbound IP rules that allow only your trusted IP ranges, and save.
    
3.  Confirm the application is no longer reachable from untrusted networks.
    

**Backout Plan**

1.  Delete the inbound IP rules from the service's Settings page, or restore the public web service if it was replaced.
    

**Reference**

-   [https://render.com/docs/private-services](https://render.com/docs/private-services)
    
-   [https://render.com/docs/inbound-ip-rules](https://render.com/docs/inbound-ip-rules)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.