{"id":40922,"date":"2026-09-21T10:33:40","date_gmt":"2026-09-21T10:33:40","guid":{"rendered":"https:\/\/nodemaven.com\/?p=40922"},"modified":"2026-09-21T10:36:27","modified_gmt":"2026-09-21T10:36:27","slug":"nodemaven-product-updates","status":"publish","type":"post","link":"https:\/\/nodemaven.com\/ru\/blog\/nodemaven-product-updates\/","title":{"rendered":"NodeMaven Updates: Building the Infrastructure for Next-Gen Web Operators"},"content":{"rendered":"

Over the past few months, we released \u0411\u0440\u0430\u0443\u0437\u0435\u0440 \u0434\u043b\u044f \u0441\u043a\u0440\u0435\u0439\u043f\u0438\u043d\u0433\u0430<\/a>, improved session control, rebuilt parts of the ISP proxy experience, added a set of free diagnostic tools<\/a>, and made a long list of improvements behind the scenes.<\/p>\n\n\n\n

I could give you the changelog version, but would rather explain what led us to each update.<\/p>\n\n\n\n

Most of this work came from practical problems our users were running into. Even with so many browser automation products on the market, they were still looking for a setup flexible enough for different workflows. We kept working on the stability of our proxy sessions, especially for longer workflows. We also saw a need of users for a quicker way to understand why a request had failed, they were blocked or whether their real IP was exposed. That led us to start building a free set of diagnostic tools. NodeMaven has been growing quickly, so we also spent a lot of time on backend work. We expanded capacity and strengthened our infrastructure to support that growth and improve resilience.<\/p>\n\n\n\n

Here are our major updates from the past several months.<\/p>\n\n\n\n

The browser launch was the obvious headline<\/strong><\/h2>\n\n\n\n

AI agents are getting better<\/strong> at planning a task and writing the code for it, but they still need somewhere to run that code.<\/p>\n\n\n\n

The open web is a difficult working environment. Pages render content with JavaScript, buttons appear after network calls, sessions depend on cookies, and location can change the page an agent sees.<\/p>\n\n\n\n

Recently, I shared a study<\/a> \u043d\u0430 X<\/a> \u0438 LinkedIn<\/a>. The system worked from screenshots instead of reading the page\u2019s code and reached 85.4% accuracy in a test covering 16 CAPTCHA classes.<\/p>\n\n\n\n

Website operators also have good reasons to examine automated traffic closely. Imperva\u2019s 2026 Bad Bot Report<\/a>, based on full-year 2025 activity, found that automated traffic accounted for more than 53% of all web traffic<\/strong>, up from 51% in 2024. Akamai measured an average of 2.5 billion AI-bot requests per day<\/strong><\/a> across its network and reported that AI-related traffic nearly doubled during the second half of 2025.<\/p>\n\n\n\n

These were some of the reasons to develop \u0431\u0440\u0430\u0443\u0437\u0435\u0440 \u0434\u043b\u044f \u0441\u043a\u0440\u0430\u043f\u0438\u043d\u0433\u0430 NodeMaven<\/strong><\/a>. It gives an agent or developer a cloud browser with full JavaScript rendering, NodeMaven residential and mobile proxy traffic, aligned browser and location settings, persistent profiles, supported CAPTCHA handling, and tools for watching and debugging a run. I shared more about why we brought the browser and proxy layers together in this LinkedIn post<\/a>.<\/p>\n\n\n\n

You can write AI prompt, start from a template, or connect Playwright and Puppeteer over CDP. Live Browser<\/strong> shows what is happening on the page. Screenshots, recordings, console output, and structured JSON<\/strong> help when the result looks wrong.<\/p>\n\n\n\n

For users working with AI agents, we recently added a button to copy setup prompt<\/strong> for your agent. It copies the Scraping Browser setup context from the dashboard, ready to paste into an agent along with the task and required output. For example, an agent can navigate a JavaScript-heavy product catalog, keep the selected location and session state across the run, and return the requested fields as JSON. If something is missing, the recording and browser output provide a place to start debugging.<\/p>\n\n\n\n

Scraping Browser is available to customers with an active residential proxy subscription. There is no separate browser runtime charge<\/strong> for eligible users. Sessions use proxy traffic from the plan.<\/p>\n\n\n\n

Improving sticky sessions<\/strong><\/h2>\n\n\n\n

We also worked on our Super Sticky Sessions. When a customer selects \u0421\u043e\u0445\u0440\u0430\u043d\u044f\u0439\u0442\u0435 IP-\u0430\u0434\u0440\u0435\u0441 \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0434\u043e\u043b\u044c\u0448\u0435<\/strong>, the assigned IP now stays in place for longer. This helps with logged-in and multi-step browser flows, where an IP change halfway through can mean starting again. The setup in the dashboard stays the same.<\/p>\n\n\n\n

If a workflow needs the same IP over a long period, I would usually recommend our ISP \u043f\u0440\u043e\u043a\u0441\u0438<\/a>. Still, some customers use \u0440\u043e\u0442\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0440\u0435\u0437\u0438\u0434\u0435\u043d\u0442\u0441\u043a\u0438\u0435 \u043f\u0440\u043e\u043a\u0441\u0438<\/a> and need the IP to remain unchanged during a session. We added a no-rotate<\/strong> option for those cases. If the assigned IP becomes temporarily unavailable, NodeMaven waits for it to return instead of moving the session to another IP. This can prevent another verification or a full restart during a logged-in, multi-step flow.<\/p>\n\n\n\n

We made ISP proxies easier to manage<\/strong><\/h2>\n\n\n\n

We made several changes to the way ISP proxy packs are delivered and managed.<\/p>\n\n\n\n

Before delivery, new ISP proxy packs go through our internal quality checks<\/strong>. Customers also have a full-pack swap button<\/strong> in the dashboard. It can be used once for a newly issued pack, without contacting support.<\/p>\n\n\n\n

We rebuilt the ISP section of the dashboard<\/a> with order notes, search, clearer IP details, and direct proxy checks<\/strong>. We also made subscriptions and auto-renewal<\/strong> easier to control.<\/p>\n\n\n\n

We also noticed that a missed manual renewal could interrupt workflows already running on those IPs. So we added renewal reminders<\/strong> \u0438 24-hour extension<\/strong> after expiry, giving customers more time to renew the pack.<\/p>\n\n\n\n

\u0417\u0430\u043c\u0435\u0442\u043a\u0430:<\/strong> Our team has covered the quality checks, renewal controls, and ISP dashboard changes<\/a> in more detail in a separate post.<\/p>\n\n\n\n

Infrastructure improvements<\/strong><\/h2>\n\n\n\n

A large part of our work this cycle was on the infrastructure behind the product.<\/p>\n\n\n\n

We expanded our server fleet to add more capacity and redundancy<\/strong>, and reworked load balancing<\/strong> so traffic is distributed more evenly. This gives the network more headroom during peak demand and reduces bottlenecks.<\/p>\n\n\n\n

We also continued strengthening network-level security<\/strong> and introduced \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0435\u043d\u0438\u0435 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u0438<\/strong> to protect service quality and ensure fair access to shared resources as traffic grows.<\/p>\n\n\n\n

The team fixed a resource leak<\/strong> in a core backend service that could gradually affect performance during long-running operation. Resolving it reduces slowdowns and unexpected restarts, helping the service remain consistent over time.<\/p>\n\n\n\n

We also optimized communication between the proxy layer and our caching and session infrastructure<\/strong>. This reduces unnecessary backend work and supports faster response times and higher throughput.<\/p>\n\n\n\n

This was one of my favorite pieces of work our team has done in the past few months. There is no new setting in the dashboard, but these changes give us more capacity during traffic peaks and more consistent performance under load<\/strong>.<\/p>\n\n\n\n

\u0417\u0430\u043c\u0435\u0442\u043a\u0430:<\/strong> Our team has explained more of the topic in the infrastructure improvements update<\/a> post.<\/p>\n\n\n\n

Free proxy and browser diagnostic tools<\/strong><\/h2>\n\n\n\n

I asked a question on X<\/a> recently: when your scraper gets blocked, what do you blame first, the proxy or the browser?<\/p>\n\n\n\n

My first check is the direct connection<\/strong>. If the same request fails without a proxy, swapping the proxy is unlikely to solve it. From there, I look at the browser, the machine running the script, the DNS path, and the target itself.<\/p>\n\n\n\n

We published six free browser-based tools<\/strong> to make those first checks quicker:<\/p>\n\n\n\n