DEV Community: Aleksandr Kubarskii

I'm building Inquir Compute. Here's how deployment works.

Aleksandr Kubarskii — Mon, 05 Oct 2026 12:15:21 +0000

I'm building Inquir Compute, a cloud platform for apps, databases, and background jobs.

The kind of setup I have in mind is pretty common: an API, PostgreSQL, and maybe a worker. I can put those on a VPS, but then I'm also setting up HTTPS, collecting logs, and maintaining deployment scripts. For a small project, I'd rather spend that time on the app.

Inquir lets you deploy from a GitHub repository, a Dockerfile, or an existing container image. The app can stay a regular HTTP server. You don't have to rewrite it around a platform-specific handler.

Here's how deployment works with a small Node.js app. We'll deploy it, check a second version on a preview URL, and then roll back.

The app

You'll need Node.js 22 or later for the CLI and an Inquir account with available resources. Use a workspace where you're the owner or an admin so you can promote releases. There's a note about account access at the end.

Create a directory:

mkdir inquir-demo
cd inquir-demo

Add server.mjs:

import { createServer } from 'node:http';

const port = Number(process.env.PORT ?? 3000);
if (!Number.isInteger(port) || port < 1 || port > 65535) {
  throw new Error('PORT must be an integer between 1 and 65535');
}

const version = 'v1';
const server = createServer((req, res) => {
  if (req.method === 'GET' && req.url === '/healthz') {
    res.writeHead(200, { 'content-type': 'text/plain; charset=utf-8' });
    return res.end('ok');
  }

  if (req.method === 'GET' && req.url === '/') {
    res.writeHead(200, { 'content-type': 'application/json' });
    return res.end(JSON.stringify({ message: 'Hello from Inquir', version }));
  }

  res.writeHead(404, { 'content-type': 'text/plain; charset=utf-8' });
  res.end('Not found');
});

server.on('error', (error) => {
  console.error(error);
  process.exit(1);
});
server.listen(port, '0.0.0.0', () => console.log(`Listening on ${port}`));

for (const signal of ['SIGTERM', 'SIGINT']) {
  process.once(signal, () => {
    server.close(() => process.exit(0));
    setTimeout(() => process.exit(1), 5000).unref();
  });
}

The app returns its version at / and responds to health checks at /healthz. It listens on 0.0.0.0, reads PORT from the environment, and handles shutdown signals. There are no external dependencies.

Add a Dockerfile:

FROM node:22-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY --chown=node:node server.mjs ./server.mjs
USER node
EXPOSE 3000
CMD ["node", "server.mjs"]

To try it locally:

node server.mjs

Then, in another terminal:

curl http://localhost:3000/healthz
curl http://localhost:3000/

You should get ok from the health endpoint and JSON containing "version": "v1" from /.

Deploying it

Install the CLI and log in:

npm install -g @inquir/compute-cli
inquir login
inquir workspaces
inquir use WORKSPACE_SLUG

Replace WORKSPACE_SLUG with the slug or ID shown by inquir workspaces.

Create a project and select it:

inquir projects create devto-demo --slug devto-demo
inquir projects use devto-demo

Then create the app and deploy it from the directory containing the Dockerfile:

inquir apps create web --port 3000 --health-path /healthz
inquir apps deploy web

The build runs on Inquir, so you don't need Docker installed locally. Once the release starts and passes its health check, you get a preview URL.

Open it and check that the app returns v1. To see its status and logs:

inquir apps status web
inquir apps logs web --tail 100

When you're happy with the preview, promote the release and make the app public:

inquir apps promote RELEASE_ID
inquir apps update web --ingress public
inquir apps status web

Use the release ID from the deployment or status output for RELEASE_ID. It isn't the app name. The production URL will appear in the status output too.

Promotion and public access are separate settings. You can keep a service internal even after promoting its release.

Deploying a second version

Change this line in server.mjs:

const version = 'v1';

to:

const version = 'v2';

Deploy again:

inquir apps deploy web

This app has no persistent volume, so the new release can run alongside the old one. The preview URL should return v2. Production still returns v1.

That gives you time to check the actual app before switching traffic. Passing /healthz only tells us the server can respond. It could still be returning the wrong data or failing on another endpoint.

To put the new version into production:

inquir apps promote NEW_RELEASE_ID

Use the ID of the new release here. To go back to the previous one:

inquir apps rollback web

If the previous container is still running on standby, traffic can switch back to it. Otherwise, Inquir has to start it again and wait for the health check.

One important detail: rollback only restores the application release. It won't undo a database migration, recover deleted records, or take back a request you've already sent to another service.

Adding a database or a worker

You can create PostgreSQL from a template with a persistent volume. The inquir apps connect command puts its connection string into the app's environment as DATABASE_URL. You need to deploy a new release for that variable to take effect.

Your code still needs a database driver or ORM. Inquir handles the connection configuration, not your queries or migrations.

A worker can run as a long-lived container in the same project. Functions and pipelines are also available for individual calls, webhooks, and scheduled tasks. You don't have to squeeze a process that needs to stay running into a function.

Current limits

There are a couple of things worth knowing before putting a real project on it.

Writable persistent volumes are tied to a single host. An app using one has one replica, with no automatic volume replication or live migration. Updating it means stopping the old container before starting the new one, so there is downtime. The side-by-side deployment above applies to our stateless example, not to an app writing to a persistent volume.

Container scaling is manual for now. You can set resources and the supported number of replicas, but the platform won't automatically add replicas when traffic increases.

Trying it with your app

I'm looking for developers willing to try a small project and tell me what gets in the way. An API with a database, a background worker, or an internal tool would all be useful to test. Start with something non-critical and try updating it too, not just getting the first version online.

The deployment docs have more detail on the commands above.

What are you using to host your apps now, and what part of the setup would you most like to stop doing yourself?

Building Inquir Compute: Serverless Functions for AI Agents, Background Jobs, and Long-Running Workflows

Aleksandr Kubarskii — Fri, 15 May 2026 14:07:22 +0000

Most serverless platforms are great when your function is small, stateless, and finishes quickly.

But modern AI applications often do not look like that.

They need to:

run background jobs
process files
call LLMs
execute multi-step pipelines
expose API endpoints
handle webhooks
run scheduled tasks
keep containers warm
preserve logs and traces
avoid Kubernetes complexity

That is the problem I am working on with Inquir Compute.

Inquir Compute is an AI-first Function-as-a-Service platform designed for developers who want to deploy functions, API endpoints, cron jobs, webhooks, and background workflows without managing Kubernetes, containers, ingress, scaling logic, or infrastructure boilerplate.

Why I started building it

I originally worked on Inquir as a search-as-a-service product.

The idea was simple: help developers build search engines over different data sources.

But while building ingestion pipelines, I noticed something interesting.

A lot of the hard parts were not just about search.

They were about compute.

For example:

fetch data from external APIs
normalize and enrich documents
split content into chunks
call AI models
index the result
retry failed steps
run jobs on a schedule
expose parts of the workflow through HTTP APIs

At some point, the ingestion pipeline itself became the most interesting part of the system.

That was the pivot.

Inquir Compute was born from the idea that AI applications need a simpler way to run server-side logic.

Not just short-lived functions.

But real workflows.

The problem with traditional serverless

AWS Lambda, Vercel Functions, Cloudflare Workers, and similar platforms are powerful.

But when you build AI-heavy systems, you quickly hit limitations.

Some common issues:

1. Timeouts

AI workflows are not always fast.

A function may need to:

process a large document
call multiple LLM APIs
wait for an external service
crawl a website
transform data
execute several dependent steps

Short execution limits become painful very quickly.

2. Cold starts

For many APIs, cold starts are acceptable.

For AI agents and interactive workflows, they are not always acceptable.

If a user is waiting for an agent to respond, container startup time matters.

3. Background jobs are awkward

A lot of platforms are optimized for request-response functions.

But real products need background work:

send emails
process uploads
generate reports
sync data
update embeddings
call webhooks
clean old records
run scheduled tasks

Developers often end up connecting several services together just to run a job reliably.

4. Kubernetes is too much for small teams

Kubernetes is powerful, but it is also a lot of operational overhead.

For many indie hackers, startups, and small engineering teams, the ideal experience is:

I write a function, deploy it, expose it as an API, schedule it, and see logs.

Not:

I configure deployments, services, ingress, secrets, volumes, autoscaling, observability, and routing manually.

What Inquir Compute does

Inquir Compute is a serverless compute platform focused on developer experience.

The core idea is simple:

Write backend logic as functions and run them as APIs, cron jobs, webhooks, background tasks, or pipeline steps.

A function can be used in different ways.

For example, the same function could be:

exposed as an HTTP endpoint
triggered by a cron schedule
called inside a pipeline
used as a webhook handler
executed manually from the dashboard
used by an AI agent

Example: a simple function

A function can be as simple as this:

export default async function handler(event) {
  const name = event.queryStringParameters?.name || "developer";

  return {
    statusCode: 200,
    body: {
      message: `Hello, ${name}!`,
    },
  };
}

Then it can be mapped to an API route like:

GET /hello

And called from the outside:

curl https://your-domain.com/api/gw/workspace/hello?name=Alex

The goal is to make deployment feel closer to writing application logic, not managing infrastructure.

API endpoints

Inquir Compute includes an API Gateway-like layer.

That means functions can be mapped to routes:

GET /users/:id
POST /webhooks/stripe
POST /agent/chat
GET /reports/:reportId

The function receives an event object similar to common serverless platforms:

export default async function handler(event) {
  const userId = event.pathParameters.id;

  return {
    statusCode: 200,
    body: {
      userId,
      message: "User profile loaded",
    },
  };
}

This makes it possible to build small APIs without setting up a traditional backend server.

Cron jobs

AI and data applications often need scheduled execution.

For example:

run a daily sync
update search indexes
refresh cached data
send scheduled reports
check external APIs
run cleanup jobs

With Inquir Compute, the goal is to make cron a first-class concept.

Example:

0 2 * * *

This could trigger a function every day at 2 AM.

export default async function handler() {
  console.log("Running nightly sync");

  // Fetch data
  // Transform it
  // Store it
  // Send report

  return {
    statusCode: 200,
    body: {
      ok: true,
    },
  };
}

Webhooks

Webhooks are another common use case.

You may want to receive events from:

Stripe
GitHub
Telegram
Slack
Notion
custom internal systems

Instead of running a full server just to receive webhook events, you can deploy a function:

export default async function handler(event) {
  const payload = JSON.parse(event.body);

  console.log("Webhook received:", payload);

  return {
    statusCode: 200,
    body: {
      received: true,
    },
  };
}

Then expose it as:

POST /webhooks/github

Pipelines

One of the most important concepts in Inquir Compute is the pipeline.

AI workflows are rarely a single function.

They are usually a chain of steps:

Fetch data
→ Clean data
→ Chunk content
→ Generate embeddings
→ Store result
→ Notify user

Or:

Receive user request
→ Call LLM
→ Search knowledge base
→ Call another tool
→ Generate response
→ Save trace

A pipeline can be sequential or parallel.

Some steps may depend on previous steps.

Some steps may need retries.

Some may have conditions.

The long-term goal is to make these workflows easy to build and observe.

Hot containers

A major design idea behind Inquir Compute is keeping containers warm.

Instead of always starting a new container for each invocation, Inquir Compute can keep function containers available for reuse.

This is especially useful for AI workloads where startup time can be expensive.

For example, a function may need to load:

an SDK
a model client
configuration
cached data
dependencies
initialization logic

Keeping containers warm can improve the developer and user experience.

Observability by default

Serverless is only useful if you can understand what happened.

For each function or pipeline run, you need visibility into:

logs
execution time
errors
input/output
failed steps
retries
traces

Inquir Compute is designed with built-in observability so developers do not need to wire everything manually from day one.

Why not just use Kubernetes?

You can absolutely build something like this on Kubernetes.

In fact, under the hood, many platforms eventually need container orchestration concepts.

But most developers do not want to start there.

For many projects, Kubernetes is too low-level.

You need to think about:

deployments
services
ingress
autoscaling
secrets
namespaces
persistent volumes
container lifecycle
monitoring
networking

Inquir Compute tries to hide most of that behind a simpler abstraction:

Function → Route → Job → Pipeline → Logs

The developer should focus on application logic.

Who is it for?

Inquir Compute is mainly for developers building:

AI agents
internal tools
SaaS backends
data pipelines
webhook-based systems
scheduled jobs
API endpoints
automation workflows
document processing systems
search and RAG pipelines

It is especially useful when you want serverless simplicity but need more flexibility for long-running or background workloads.

Example use case: AI content pipeline

Imagine you want to build an AI content pipeline.

The workflow could look like this:

1. Read topic from database
2. Generate article outline
3. Generate draft
4. Improve SEO
5. Generate social post
6. Save result
7. Send notification

Each step can be a separate function.

export default async function generateOutline(event) {
  const { topic } = event.input;

  // Call LLM here

  return {
    outline: [
      "Introduction",
      "Problem",
      "Solution",
      "Example",
      "Conclusion",
    ],
  };
}

Then another function can generate the article.

Another one can create a LinkedIn post.

Another one can publish or schedule the result.

This is the kind of workflow that does not always fit well into classic request-response serverless functions.

The bigger vision

I think AI applications need a new kind of backend platform.

Not just hosting.

Not just functions.

Not just containers.

But a compute layer designed around:

agents
tools
workflows
long-running tasks
scheduled jobs
API routes
observability
developer experience

That is what I am trying to build with Inquir Compute.

Current status

Inquir Compute is still evolving, but the core direction is clear:

deploy functions from the browser
expose functions as API endpoints
run background jobs
run cron jobs
build pipelines
keep containers warm
provide logs and traces
reduce infrastructure overhead

The goal is not to replace every cloud platform.

The goal is to make it much easier to build and run AI-first backend logic.

Final thoughts

Serverless made backend deployment much simpler.

But AI applications are changing what backend workloads look like.

They are longer-running.

They are more stateful.

They depend on external APIs.

They need background execution.

They need orchestration.

They need visibility.

And they should not require every developer to become a Kubernetes expert.

That is why I am building Inquir Compute.

If you are building AI agents, automation workflows, data pipelines, or serverless backends, I would love to hear what problems you are running into.

In case you like it, I will share more insights on technical solutions I came up to.