An IPv4 broker helps companies source address space and coordinate the commercial and technical arrangements needed to use it. PubConcierge operates as a global IPv4 leasing provider and managed IP broker, combining resource sourcing with reputation screening, technical setup, routing support, and account management. Its role connects the leasing decision with the work required to bring the addresses into production.
For a company expanding a hosting platform, VPN network, proxy service, or data operation, the practical question is simple: what needs to happen before these IPs can support our workload? Capacity, authorization, routing, geographic recognition, and application compatibility all influence the answer.
This guide explains how to evaluate PubConcierge for that journey, which responsibilities belong in the proposal, and what your team should test before scaling. For broader capacity planning, explore our guide to IPv4 exhaustion strategies.
Key Facts
• PubConcierge combines IPv4 sourcing with managed services for business deployments.
• Address-space leasing and managed proxy services have different delivery requirements.
• A production plan needs named owners for authorization, network setup, testing, and support.
• Reputation screening must be paired with checks in the intended application.
• Evaluate accepted capacity, deployment effort, and continuity alongside the monthly rate.
- What PubConcierge does as an IPv4 broker
- Choose the delivery model before comparing quotes
- From IP sourcing to production with PubConcierge
- Case Study helping a Proxy Provider deploy 4,096 IPv4 addresses
- What to verify before production
- Compare total deployment cost and continuity
- Frequently Asked Questions
What PubConcierge does as an IPv4 broker
IPv4 brokerage can cover purchases, leases, or both. A purchase involves a different commercial and registry process from leasing. This article focuses on leasing: your company receives agreed rights to use address space for a defined period without purchasing it outright.
PubConcierge brings brokerage and managed leasing services together. Buyers can discuss the available capacity alongside the infrastructure and operational support their deployment requires. The useful outcome is a proposal that engineering, procurement, and finance can evaluate against the same requirements.
That matters when the request spans several teams. Procurement needs clear terms and documented authority to provide the resource. Engineering needs a compatible delivery method. Operations needs a support contact and a plan for changes after launch. Those requirements should be visible before the order is approved.
PubConcierge also offers proxy, dedicated server, and cloud services. These may be relevant to the delivery design, but their availability does not mean every IPv4 lease includes them. The PubConcierge service overview is a starting point for selecting the appropriate scope.
Choose the delivery model before comparing quotes
A company that wants to announce a leased prefix on its own network needs a different arrangement from a company buying managed proxy access. Establish which product you need before comparing capacity, pricing, or onboarding estimates.
| Delivery model | What your team needs to establish |
| Address space on your network | Receiving network, origin ASN, routing authorization, configuration owner, and upstream acceptance |
| Address space on another provider’s network | Provider compatibility, announcement responsibility, required documents, and change process |
| Managed infrastructure or proxy service | Service endpoints, access method, supported workload, geographic requirements, and included infrastructure |
Cloud Bring Your Own IP, or BYOIP, adds platform-specific requirements. A leased block is not automatically eligible for every cloud. Validate the intended prefix and authorization arrangement with the receiving platform before committing to that delivery path.
From IP sourcing to production with PubConcierge
The following stages give buyers a practical framework for planning a deployment with PubConcierge. The precise sequence and included tasks depend on the resource, receiving network, and agreed service.
1. Match capacity to the workload
Begin with the application and network design. Include current demand, expected growth, preferred region, lease duration, and the infrastructure that will receive the addresses. If geographic recognition or a particular network profile matters, identify the services that will evaluate it.
A /24 contains 256 addresses, a /22 contains 1,024, and a /20 contains 4,096. These are total counts; usable capacity depends on the design. The IPv4 subnet cheat sheet helps translate a capacity requirement into prefix sizes.
For example, a hosting business requesting a /22 should explain how the addresses will be allocated to customers, where the block will be announced, and whether reverse DNS is required. That information makes the sourcing request more useful than an address count alone.
2. Evaluate the candidate resource
PubConcierge provides reputation screening. For your deployment, connect that screening to the candidate prefix, the review date, and the application. A dated result is useful evidence for a decision; reputation can change after delivery.
Different blocklists answer different questions. Spamhaus explains that its Policy Blocklist identifies addresses that should not send mail directly to receiving mail servers. A PBL listing therefore needs to be interpreted in the context of the proposed use. See the Spamhaus PBL explanation.
Geolocation requires a separate check. RIPE NCC explains that it is not a geolocation provider; registry attributes may inform third-party databases, but they do not guarantee uniform location recognition. Test the databases and applications that matter to your business. See RIPE Database geolocation guidance.
3. Align authorization and network setup
For a routed prefix, the deployment plan should identify the receiving network, origin Autonomous System Number, or ASN, and the party responsible for each authorization task. Public registry records identify the registered holder, but the proposal should also establish the authority to provide the specific lease.
A Letter of Authorization, or LOA, documents permission for the specified announcement. Internet Routing Registry route objects describe routing information. Resource Public Key Infrastructure, or RPKI, provides route-origin authorization through Route Origin Authorizations, or ROAs. These documents and records serve related but distinct purposes.
ARIN defines a ROA as a signed object identifying the ASN authorized to originate a prefix. The intended announcement must align with the applicable authorization, including prefix length. Use ARIN’s ROA documentation as a technical reference.
PubConcierge offers routing and rDNS/PTR support. Where a tunnel or managed infrastructure is proposed, validate the design against the receiving network and workload. Record which tasks PubConcierge will perform and which require the resource holder, your engineers, or another provider.
4. Test the actual workload
PubConcierge offers free IP testing. Establish the available test scope, delivery arrangement, and duration for your order. The pilot should reflect the conditions under which the resource will be used, with acceptance criteria agreed before testing starts.
A successful connectivity check does not establish application suitability. A hosting service needs to validate the services its customers use. A VPN operator needs to check the intended exit location and connection behavior. A data team needs to test permitted collection workflows under representative request patterns.
Keep a record of the prefix, configuration, test dates, results, and unresolved issues. This gives both teams a shared basis for acceptance or further investigation. Our IP leasing testing guide explains how to plan that evaluation.
5. Establish the operating relationship
After acceptance, the deployment still needs support and change management. PubConcierge provides dedicated account management and 24/7 technical support. The order should specify the relevant contacts, escalation path, and coverage for the purchased service.
Support availability, response commitments, and replacement eligibility are separate details. Document the applicable terms, including how routing changes, reputation concerns, or renewal questions will be handled. Keep deployed-prefix records and renewal dates accessible to your operations team.
PubConcierge Service Scope and Customer Responsibilities
PubConcierge’s published offering includes sourcing, reputation screening, technical setup, routing support, rDNS/PTR configuration, testing, and account management. The table below distinguishes those advertised capabilities from tasks that depend on the delivery design. A capability is included in your order only when the proposal or agreement specifies it.
| Service or task | PubConcierge scope | Customer or external dependency |
| IP sourcing and screening | Advertised capability; exact prefix and screening scope defined in the order | Provide quantity, region, workload, and acceptance requirements |
| Free testing | Advertised offer; availability, duration, and access method agreed for the product | Run representative application tests and decide acceptance |
| LOA and routing support | Routing support advertised; document and coordination tasks assigned in the proposal | Supply intended ASN and receiving-provider requirements |
| IRR and RPKI/ROA | Order-dependent coordination; identify the authorized record manager | Resource holder or authorized manager makes record changes; receiving network checks compatibility |
| rDNS/PTR | Advertised capability; configuration or delegation scope agreed | Provide hostnames and any required forward DNS configuration |
| BGP and cloud setup | Managed support depends on the contracted delivery model | Customer or receiving provider configures its network and confirms cloud eligibility |
| Tunnels and hosting | Available capabilities; specify separately if part of the deployment | Provide endpoint details and validate receiving infrastructure |
| Account management and support | Dedicated account management and 24/7 support advertised | Name technical contacts and record agreed escalation terms |
| Monitoring and replacement | Coverage, eligibility, and remedies must be stated in the order | Report issues with logs and follow agreed usage and incident procedures |
For address space announced on your own network, your team or receiving provider operates that network unless management is expressly contracted. For managed proxy services, access methods, pools, session settings, and dashboard features belong to the chosen proxy product. Do not use a proxy feature list as the scope of an address-space lease.
Case Study helping a Proxy Provider deploy 4,096 IPv4 addresses
The Requirement
A proxy provider needed 4,096 IPv4 addresses—a /20—to expand its datacenter proxy service in Europe. It planned to announce the block through its infrastructure partner and allocate the addresses across customer proxy pools.
The provider required reputation screening, routing authorization, and workload testing before rollout. Its target was production acceptance within five business days of submitting complete deployment requirements.
The Deployment Challenge
The receiving network required an LOA and routing records aligned with its origin ASN. Responsibility for coordinating those records had not been established.
The provider also needed to evaluate the addresses against representative customer workloads. Network reachability alone would not establish whether the capacity met its application and geographic requirements.
What PubConcierge Did
PubConcierge sourced a candidate /20 and coordinated a reputation review against the agreed screening criteria. The team worked with the authorized resource holder and infrastructure partner to arrange the LOA and coordinate the required IRR and RPKI/ROA updates.
The proxy provider configured its proxy software, authentication, customer allocations, and session settings. Its infrastructure partner configured the network and announced the prefix.
Before customer allocation, the teams ran a 48-hour pilot covering reachability, geographic recognition, connection behavior, and representative permitted customer workflows. They recorded issues and assigned an owner to each before acceptance.
The Outcome
The provider accepted the deployment within five business days of submitting complete requirements. All 4,096 addresses met the agreed resource acceptance criteria, with no unresolved routing or authorization issues at launch.
The provider then introduced the capacity into customer pools in stages, using the pilot configuration and test records as the basis for rollout.
These assumed results illustrate how coordinated sourcing, authorization, and testing could support deployment.
What to verify before production
Agree the checks that apply to your workload rather than using a single definition of “working IPs.” Keep the evidence and the decision together.
| Check | Evidence to retain |
| Routing and authorization | Observed origin ASN, applicable authorization, route visibility, and receiving-provider approval |
| Reachability | Results from representative external networks and required application ports |
| Reputation | Sources checked, timestamps, relevant findings, and unresolved issues |
| Geographic recognition | Results from named databases or applications relevant to the market |
| Reverse DNS where required | PTR lookup results and the process for future changes |
| Application suitability | Representative workload results against agreed acceptance criteria |
These checks expose different risks. Correct routing does not guarantee inbox placement, a specific geographic classification, or acceptance by a third-party platform. Workload testing helps your team distinguish resource problems from application settings, rate limits, or platform policies.
Compare total deployment cost and continuity
Compare offers using the same workload and acceptance standard. Include recurring lease charges, setup, receiving infrastructure, and any additional managed services. Internal engineering effort and the cost of a delayed launch also affect the decision. Our IP leasing price guide explains the main pricing considerations.
For illustration, a /24 at $0.45 per address per month costs $115.20 before other charges. If 240 addresses satisfy the agreed criteria, that lease charge equals $0.48 per accepted address. This is a hypothetical calculation, not a PubConcierge quote or customer result.
Acceptance requirements matter as much as the arithmetic. If your application requires the whole prefix, partial acceptance may be unsuitable regardless of the effective price. Our IPv4 leasing market analysis offers broader market context.
Continuity belongs in the commercial review. Identify lease duration, billing commencement, renewal notice, permitted use, termination conditions, and any remediation or replacement provisions. Our guide to customizing IP leasing agreements helps procurement connect contract terms to operational requirements.
Plan your IPv4 deployment with PubConcierge
Bring your capacity requirements, receiving infrastructure, and acceptance criteria to PubConcierge. Discuss the available IPs, delivery model, free testing options, and managed support your team needs.
Frequently Asked Questions
What does an IPv4 broker like PubConcierge do?
PubConcierge helps businesses source leased IPv4 resources and supports evaluation, technical setup, routing, and ongoing management. The proposal defines which services apply to the particular order.
How can PubConcierge help get leased IPs into production faster?
Its sourcing and managed support can help coordinate the requirements, delivery arrangement, and technical handoffs. Identifying authorization, receiving-network requirements, and test criteria early can reduce avoidable rework. Actual timing depends on resource availability, configuration, and external approvals.
Can my company test IPs before committing?
PubConcierge offers free IP testing. Establish the available test scope and duration for your intended product, then evaluate the resource against workload-specific acceptance criteria.
Do I need my own ASN to lease IPv4?
It depends on who will announce the addresses. A deployment on your own network differs from one operated by a hosting provider or managed service. Set the delivery arrangement before determining the ASN and authorization requirements.
Can leased IPv4 addresses be used with cloud BYOIP?
Potentially, if the receiving cloud accepts the prefix and its authorization arrangement. Eligibility is platform-specific, so validate the proposed resource against the cloud provider’s requirements before committing.
Does a reputation check guarantee application compatibility?
No. Reputation screening is one part of evaluation. Routing, geographic recognition, configuration, and application policies also affect usability. Test the actual workload before production rollout.
What should the proposal include?
The resource and delivery method, pricing, lease term, included services, assigned technical responsibilities, acceptance process, support scope, and applicable renewal or remediation terms.
Stay up to date on growth infrastructure, email best practices, and startup scaling strategies by following PubConcierge on LinkedIn.
