InsForge integration

Pair InsForge backend state with Jungle Grid execution

InsForge handles backend concerns such as state, storage, auth, and app data. Jungle Grid handles remote AI workload execution when your product needs compute-heavy jobs without turning the backend into a GPU scheduler.

Scope

Unofficial demo and reference integration. This page describes a practical split between InsForge as a backend layer and Jungle Grid as a remote execution layer.

Tool role

InsForge

Backend, state, storage, auth, and application data services.

Jungle Grid role

Remote execution

Remote workload executor behind the product backend.

Best use case

AI products that need a backend state layer plus tracked remote execution for heavier workloads.

Open InsForge docs

Read the docs Browse integrations

Backend state layer

Tool role

InsForge covers app data, auth, storage, and backend patterns designed for AI-assisted development.

Execution backend

Jungle Grid role

Jungle Grid runs the job and returns lifecycle updates the app can store or display.

AI products

Best fit

Good when an app needs both backend state and a clean remote execution layer.

How it works

How InsForge and Jungle Grid fit together

InsForge is useful for the product layer around an AI workload: user identity, application state, storage, file upload handling, and result metadata. Those concerns are different from scheduling and executing remote AI jobs.

A practical split is to store the workload record in InsForge, submit the actual job to Jungle Grid, then persist status transitions and result metadata back into InsForge as the job progresses. That keeps the backend product model clean while Jungle Grid handles the workload runtime.

Use InsForge for backend state, auth, storage, and app records.
Use Jungle Grid for actual workload placement and remote execution.
Store job IDs, status changes, logs metadata, and result pointers back in your backend layer.

Quick answer

InsForge stays in charge of orchestration

InsForge handles backend and app logic. Jungle Grid handles remote AI workload execution.

Keep workflow state, app behavior, and orchestration inside the integration tool. Use Jungle Grid when the job itself should run remotely with tracked status, logs, and results.

Architecture flow

Where Jungle Grid fits in the stack

The app backend owns state and user context. Jungle Grid owns the execution lifecycle for the AI job itself.

1

User / Agent / Workflow

A user action or system event starts the process that needs remote AI execution.

2

Integration tool

The orchestration layer validates input, manages state, and decides when a remote job should run.

3

Jungle Grid API

The workflow layer submits a workload request and receives a tracked job identifier back.

4

Remote AI workload execution

Jungle Grid handles placement, execution, provider capacity, and lifecycle control for the job.

5

Status + logs + result

The integration layer polls state, reads logs, and collects result payloads or failure reasons.

6

App / Agent / Workflow

The original system turns job state and outputs into the next user-facing or automated step.

Example workflow

A backend-driven product can keep its core state in InsForge while sending heavier execution to Jungle Grid and syncing status back into the app.

1

A user submits a workload request inside an application backed by InsForge.

2

InsForge stores the initial workload record, input references, and user context.

3

The app or an edge function submits the actual job to Jungle Grid.

4

Jungle Grid executes the job and exposes status, logs, and terminal state.

5

InsForge stores status transitions and result metadata so the app can render the final outcome.

Code example

Submit a workload and track the job

This example represents an app route or backend function that receives a product-level request, submits a Jungle Grid job, and then stores the returned ID in your backend state layer.

The important split is the same on every page: the integration tool decides when work should run, and Jungle Grid executes the workload remotely.

Small code exampleDemo glue code that forwards work to Jungle Grid and then checks the returned job state.

const response = await fetch("/api/junglegrid/jobs", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    workload: "inference",
    model_size: 7,
    image: "your-image:latest",
    command: "python run.py"
  })
});

const job = await response.json();

const statusResponse = await fetch("/api/junglegrid/jobs/" + job.id);
const status = await statusResponse.json();

In this demo, /api/junglegrid/jobs is an app-side route or helper endpoint that forwards work to Jungle Grid. It is shown as integration glue code, not as a claim about a fixed official URL path.

workload

The kind of job Jungle Grid should execute, such as inference, training, fine-tuning, or a batch run.

model_size

A rough sizing hint so Jungle Grid can match the workload to healthy capacity without manual GPU selection.

image

The container image Jungle Grid should launch for the workload.

command

The command executed inside the container when the job starts.

Use cases

Good fits for this pattern

This pattern is strongest when developers want to keep workflow logic inside the integration tool and avoid manually choosing GPUs, providers, or regions for each job.

Use case

AI SaaS products that need auth, state, uploads, and remote model execution in one product flow.

Use case

Document or media workflows where the backend stores asset metadata and Jungle Grid runs the compute-heavy transform job.

Use case

Applications that need reliable job tracking in product state without turning the backend into a scheduler.

Copy for LLM

Prompt an LLM with the right layer split

This prompt keeps InsForge in the orchestration role and Jungle Grid in the execution role so generated demos follow the intended architecture.

Copy for LLM

Prompt template for InsForge demos

Use this prompt when you want an LLM to scaffold a reference integration without collapsing orchestration into the execution layer.

Build a demo that uses InsForge for backend state and application logic and Jungle Grid for remote AI workload execution. The demo should submit a workload to Jungle Grid, poll job status, fetch logs, display results, and show failure/retry states. Use Jungle Grid as the execution layer, not as a replacement for InsForge.

FAQ

Frequently asked

Is this an official InsForge integration?

No. This page is an unofficial reference pattern that shows how a backend/state layer such as InsForge can work alongside Jungle Grid for remote AI workload execution.

What should stay in InsForge versus Jungle Grid?

Keep auth, data records, storage, user state, and result metadata in InsForge. Keep placement, remote execution, logs, and workload lifecycle handling in Jungle Grid.

Why split backend state from execution infrastructure?

Because product data and execution scheduling solve different problems. The split keeps your backend simpler and lets Jungle Grid focus on workload fit, capacity, and recovery.

Next step

Keep backend state and workload execution separate

Use InsForge for the app-facing backend layer and Jungle Grid for remote AI job execution so each layer stays focused on the job it is best at.

Run a workload Browse integrations

DocsRead Jungle Grid docsSee the workload-first product model, CLI, portal flow, and public docs surface behind these integration patterns.IntegrationsOpen the integrations hubCompare the other workflow, agent, backend, and app-builder patterns that connect to Jungle Grid.Webhook-driven AI workflows that need status tracking and result delivery into other systems.n8n + Jungle GridLet n8n receive events, transform data, and notify downstream systems while Jungle Grid executes the heavy AI job remotely.AI apps that need an external execution service for bigger or longer-running jobs.Dify + Jungle GridLet Dify manage prompts, tools, and app flow while Jungle Grid executes heavier workloads remotely.