DEV Community: Ceptor Labs

Introducing ReMOAT: Remote Debugging Without the Headache

Arun — Wed, 07 Oct 2026 11:52:41 +0000

Ever tried debugging a website that isn't running on your machine?

Maybe it's on a client's browser.

Maybe it's running on a Smart TV.

Maybe the bug only happens in a specific environment that you can't easily reproduce.

And then comes the usual process:

"Can you send me a screenshot?"

"Can you open DevTools?"

"What does the console say?"

"Can you try it again?"

Five minutes later, you're still trying to figure out what actually went wrong.

That's the problem ReMOAT is trying to solve.

What is ReMOAT?

ReMOAT is a remote debugging tool that lets developers debug browser-based applications remotely in real time.

Instead of asking someone to explain what they're seeing, you can connect to the browser and investigate the problem yourself.

You can inspect what's happening, check console errors, look at network activity, interact with the page, and troubleshoot issues while the problem is actually happening.

Debug the actual environment

One of the frustrating parts of debugging is that:

"It works on my machine."

The application might work perfectly in your local browser but fail on another device or environment.

ReMOAT is designed to let you debug the actual browser session instead of trying to recreate the problem from screenshots and descriptions.

The workflow becomes:

User encounters a bug
        ↓
Connect to the browser
        ↓
Inspect the actual environment
        ↓
Find the problem
        ↓
Fix it

Much less guessing.

No more screenshot debugging

Screenshots are useful, but they rarely tell the whole story.

A screenshot can't show you:

What happened in the console
Which network request failed
What the page state was
What the browser was actually doing
Whether the issue is reproducible

With remote debugging, you can investigate the problem directly.

Built for real-world debugging

ReMOAT is useful for more than just normal websites.

It can help with browser-based applications and environments where reproducing the exact issue locally can be difficult.

You can use it for things like:

Remote browser debugging
Console error investigation
Network debugging
Local storage inspection
Reproducing frontend issues
Real-time collaboration
Debugging applications on remote devices

The goal is simple:

See the problem. Don't just hear about it.

Why ReMOAT?

Tools like browser DevTools are excellent when the browser is right in front of you.

The problem starts when the browser is somewhere else.

That's where remote debugging becomes useful.

Instead of sending instructions back and forth, ReMOAT gives developers a way to get closer to the actual environment where the bug is happening.

You can check out ReMOAT here:

https://remoat.dev/

And I'd genuinely like to hear from other developers:

What's the most painful remote debugging problem you've had to deal with?

Was it a browser issue, a Smart TV, a client's device, or simply a bug that refused to reproduce locally?

Introducing ProxyCeptor: A Simpler Way to Handle APIs

Arun — Wed, 07 Oct 2026 11:41:53 +0000

_Have you ever wanted to test one small API change, but ended up spending more time setting up the environment than actually testing it?
_
Maybe you want an API to return a 500.

Maybe you want to change one field in a response.

Maybe you want to redirect a request to staging.

Or maybe you just want to see what happens when an API takes 3 seconds to respond.

Usually, you end up changing backend code, creating temporary mocks, deploying something to staging, or setting up a proxy and dealing with certificates.

That is where ProxyCeptor comes in.

Try ProxyCeptor

What is ProxyCeptor?

ProxyCeptor is a developer tool for intercepting and modifying API traffic while your application is running.

Instead of changing your backend just to test a frontend scenario, you can intercept the request and change what happens to it.

For example:

Application
     ↓
  API Request
     ↓
 ProxyCeptor
     ↓
Modify / Mock / Delay / Block
     ↓
    API

You can modify requests, change responses, mock APIs, redirect URLs, inject headers, simulate errors, and introduce network delays.

The idea is pretty simple:

Don't change your application just to test a different API scenario. Change the traffic instead.

A simple example

Imagine your API normally returns:

{
  "status": "success",
  "user": {
    "name": "John"
  }
}

You want to see how your frontend behaves when the API returns an error.

Instead of modifying the backend, you can make the response behave like:

{
  "status": "error",
  "message": "Something went wrong"
}

You can also simulate HTTP errors such as 401, 404, 500, or 503, or add artificial latency to see how your UI handles slow networks.

ProxyCeptor supports these kinds of request and response modifications directly.

What can you do with it?

Some of the useful things you can do are:

Modify request URLs
Change request payloads
Inject or modify headers
Mock complete API responses
Modify only specific JSON fields
Redirect requests
Block network traffic
Simulate API delays
Change HTTP status codes
Transform API responses

One feature I particularly like is JSON Deep Merge.

Instead of replacing an entire response, you can change only the field you care about while keeping the rest of the real API response intact.

That makes testing much less painful.

No backend changes

This is probably the biggest reason to use a tool like this.

Suppose you're working on a frontend feature that needs to handle:

"What happens when the payment API returns 503?"

You shouldn't have to ask the backend team to create a special response, deploy it, test it, and then revert it.

You can simulate that response locally and continue working.

That means frontend developers and QA engineers can test edge cases without waiting for backend changes.

And it isn't limited to browsers

ProxyCeptor can also work with Smart TV environments such as Android TV, Fire TV, Samsung Tizen, and LG webOS.

For environments where installing a root SSL certificate or configuring a traditional system proxy is painful, ProxyCeptor provides an SDK-based approach that intercepts traffic inside the application runtime.

That makes it useful for testing things that are otherwise surprisingly difficult to reproduce on real devices.

The idea behind ProxyCeptor

The goal isn't to replace your existing testing framework.

Unit tests still have their place.

Integration tests still have their place.

Mock servers still have their place.

ProxyCeptor is useful for that layer in between:

"I'm running the real application, making real requests, but I want to control what happens to those requests."

That's where API interception becomes really useful.

You can inspect the traffic, change it, reproduce an edge case, and see how your actual application reacts.

No temporary backend endpoint.

No waiting for another deployment.

Just change the traffic and test.

Give it a try

If you're working with APIs, frontend applications, QA testing, or Smart TV applications, you can try ProxyCeptor here:

https://proxyceptor.com/

There is also a live sandbox where you can experiment with API interception without setting up a project first.

I'd be interested to know how other developers handle this today.

Do you use Charles, Burp, Postman, browser DevTools, mock servers, or something else when you need to change API behavior during development?