The Complete Guide to FlowEngine Functions: Every Option Explained

FlowEngine Functions lets you deploy code to a public URL in about thirty seconds. The interface is small on purpose, but there's a lot under each panel: two runtimes, six ways to deploy, three triggers, compute knobs that go from 512 MiB to 32 GiB, three templates that handle the boring parts for you, workspace-level secrets, and structured logs. This guide walks through every option, with real screenshots from the portal.

The recommended path is MCP or the CLI. If you're working with an AI editor (Claude Code, Cursor) the MCP integration lets the model deploy, redeploy, read logs, and fix its own mistakes inside one feedback loop. If you're at the terminal, fe deploy does the same thing in one command. The browser editor, GitHub, and folder upload all work, but they involve clicking back and forth, which kills the loop. Start with MCP or CLI; reach for the others when you have a specific reason.

Skill level: beginner-friendly, reference-style. Reading time: about 12 minutes. Use it as a tour the first time, then come back to specific sections when you need them.

What FlowEngine Functions Is

Functions runs your code on demand. You write a handler, push it, and FlowEngine hands you back an HTTPS URL. Each request spins up an instance, returns a response, and shuts down.

The right use cases: webhook handlers, scheduled jobs, LLM proxies, small APIs, Slack and WhatsApp bots, scraping, anything where the function is the whole point and you don't want to babysit a server.

Runtimes

Two runtimes today, both with auto-detection of dependencies:

• Node.js 20 for JavaScript and TypeScript. Reads package.json for dependencies. Use ESM by setting "type": "module".
• Python 3.11 for Python. Reads requirements.txt.

Buildpacks figure the rest out. A Procfile overrides the default start command if you need to. No build config required.

The Six Ways to Deploy

Listed in the order you should reach for them:

1. Copy MCP (recommended for AI editors). Paste the MCP config into Claude Code or Cursor. The model can now create functions, deploy, read logs, and iterate without you copying anything between windows. This is the path that closes the loop fastest: the model sees its own deploy errors and fixes them.
2. Copy CLI (recommended for terminal work). npm i -g @flowengine.cloud/flowengine-cli && fe deploy. Push the folder you're in, get the URL back, stream logs with fe logs <name>. Same tight loop as MCP but driven by you.
3. Write code in the browser. A built-in editor with a starter index.js or main.py. Fine for tiny functions and quick demos. Slower iteration than CLI because every change is a click.
4. Start from a template. Fork a working example in one click. Best for learning by example or shipping a known pattern (WhatsApp bot, Chromium scraper, morning brief).
5. Deploy from GitHub. Paste a repo URL and branch. FlowEngine pulls the code and deploys. Auto-rebuilds on push. Best when the repo is the source of truth and you want push-to-deploy.
6. Upload folder. Drag a zip or folder onto the upload area. Best for one-off deploys without git or a CLI install.

What a GitHub-deployable repo looks like

A minimal repo that FlowEngine can deploy needs two files:

my-fn/
├── package.json
└── index.js

package.json:

{ "name": "my-fn", "type": "module" }

index.js:

export default async (req, res) => {
  res.json({ ok: true, at: new Date().toISOString() });
};

In the modal:

• Repo: your-username/my-fn (or the full URL).
• Branch: main (defaults if you leave it blank).
• Click Deploy from GitHub. Buildpacks auto-detect Node 20, the function appears in the list as Deploying, then Ready with a live URL.

Future pushes to the same branch trigger an auto-rebuild. Use this when the repo is already your source of truth; otherwise CLI or MCP is faster for active iteration.

Templates

Three templates ship today. Forking copies the code into your account and auto-provisions the secrets the template needs.

• Chromium (Node 20): Headless browser with Puppeteer preinstalled. Use for scraping, screenshots, PDF generation.
• WhatsApp bot (Node 20): Webhook handler that listens for WhatsApp messages and replies. Requires a WhatsApp instance you provision from Hosting first.
• Morning brief (Python 3.11): A cron-triggered function that pulls calendar + email and posts a digest to Slack. Auto-provisions the FlowEngine LLM key for you; you wire up Google OAuth + a Slack bot token.

The Inline Editor

If you don't want to leave the browser, the editor handles the whole flow. You get syntax highlighting, a runtime selector, and an optional name field. Click Deploy and the function appears in the list with a status badge.

Real production deploys usually graduate to the CLI or GitHub once the code grows past one file, but the editor is the fastest way to get a working URL on day one.

Compute Knobs

Four knobs control how your function runs:

• Memory: 256 MiB to 32 GiB. The free tier tops out at 512 MiB; Pro at 8 GiB; Teams at 32 GiB.
• CPU: 1 to 8 vCPU. More CPU costs more per second but a CPU-bound job finishes faster, so the total bill can be lower.
• Timeout: 1 to 3,600 seconds. Free 15s, Pro 15 min, Teams 60 min. Set it long enough to handle slow upstreams; the function gets killed at the cap.
• Concurrency: 1 to 1000 requests per instance. Higher concurrency packs more requests onto each warm instance, which lowers cost for cheap handlers and raises latency for expensive ones.

If you don't open this panel, FlowEngine picks tier-aware defaults that always validate. You only need to touch the knobs when you have a specific shape of workload (LLM call needs longer timeout, scraping needs more memory, low-latency endpoint wants high concurrency).

Min Instances and Warm Pool

On Pro and Teams, you can set minimum instances to keep one or more copies of your function warm at all times. That eliminates cold starts on latency-critical paths at the cost of paying for idle compute. Free tier is locked at zero min instances; the first call after a quiet period takes an extra second or so.

Triggers

A function can fire from three places:

• HTTP webhook (default): Every function gets a public HTTPS URL. POST data, GET query params, your handler decides what to do.
• Cron schedule: Run on a schedule. "Every weekday at 8 AM", "every 5 minutes", "first of the month". Same handler signature as HTTP; the trigger just calls the URL on the schedule.
• Slack events (Teams tier): Wire the function to your Slack workspace and fire on @mentions or events. The function gets a normalized Slack payload and a place to reply.

The Trigger panel on each function's detail page is where you switch from "HTTP only" to "HTTP + cron" or "HTTP + Slack". Switching is non-destructive; the function URL stays the same.

Secrets

Secrets live on the function detail page, under Environment & secrets. Two scopes, plus an auto-detection helper:

• Workspace secrets: Set a key once (for example OPENAI_API_KEY) and any other function in your account can reference it by name. Update the value in one place; every function picks it up on the next deploy. Best for keys you rotate centrally.
• Per-function override: Bind a secret with the same name to a specific function and that value wins for that function only. Best for test/prod splits or when one function needs a different key.
• Auto-extracted env vars: When you deploy, FlowEngine scans your code for process.env.X (Node) or os.environ['X'] (Python) references and surfaces any that aren't bound yet as a checklist. You see what's missing before the first request returns 500.

Values are encrypted at rest and never printed in logs.

The Function Detail Page

Once a function is deployed, the detail page is where you live. From top to bottom:

• Status badge: Ready, Deploying, Failed, Idle. Idle means deployed but no recent calls; Ready means deployed and active.
• Runtime row: Language + version, compute config, region (e.g. us-central1).
• Live URL: Click to copy. This is what you point webhooks at.
• This Month panel: Cost, requests, CPU-seconds, GiB-seconds. Resets on the first of each month.
• Test: Invoke the function from the portal with a request body of your choice. Returns the response inline, no curl needed.
• Re-deploy: Force a new deploy without changing the code (useful when secrets changed).
• Editor: Open the inline editor on this function's code.
• Executions: Recent invocations with status code, latency, and timestamp.
• Recent logs: The last few log entries inline, with a "full log viewer" link.
• Environment & secrets: The checklist of env vars your code references, with current values (masked).
• Trigger: HTTP only, or HTTP + cron, or HTTP + Slack events.

Executions

Executions and Logs are different things. Executions is the per-request view: one row per invocation, with the HTTP status code, latency, timestamp, and the request path. It answers "did the call at 3:17 succeed and how long did it take?"

The Executions panel on the function detail page shows the most recent invocations inline, newest first. A refresh button forces an immediate re-fetch. From here you can click into a single execution to see its full request and response payloads, the exact handler output, and any errors it threw.

Use Executions to answer questions like "is the webhook firing?", "how is my p95 latency trending today?", or "which endpoint is returning 500s right now?".

Logs

Logs are the stdout/stderr stream. Every console.log or print from your handler lands here, along with FlowEngine's own deploy-lifecycle output (deploy started, instance ready, etc.). Use the level dropdown to filter to errors only, or the search box to find a request ID. Live tail keeps the view updated in real time.

Use Logs when you need the actual print output from a specific request, or to debug a deploy that didn't come up cleanly. Both Executions and Logs are retained on every tier.

Custom Domains

On Pro and Teams, you can attach your own domain to a function. Point api.yourcompany.com at FlowEngine via a CNAME and the function answers on that hostname. TLS is provisioned automatically. Free tier uses the default fn.flowengine.cloud hostname.

CLI Quick Reference

# Install once
npm i -g @flowengine.cloud/flowengine-cli

# Log in (opens a browser to your FlowEngine account)
fe login

# Deploy the folder you're in (creates a function on first run)
fe deploy

# List your functions
fe list

# Stream logs from a function
fe logs <function-name>

# Set a secret on a specific function
fe secrets set OPENAI_API_KEY=sk-... --function <function-name>

# Open a function's portal page in the browser
fe open <function-name>

What to Build First

Pick the shape that matches your idea:

• Webhook handler: Inline editor, default compute, HTTP trigger. Done.
• Scheduled job: Inline editor or CLI, add a cron trigger, set timeout high enough for the slowest API you call.
• Slack bot: Teams tier required. Fork or write your own, set the Slack trigger, secrets for the bot token + signing secret.
• WhatsApp bot: Provision a WhatsApp instance from Hosting first, then fork the WhatsApp template.
• LLM proxy: Free tier is fine. One handler, one secret (your model API key), HTTP trigger.
• Scraper: Fork the Chromium template. Bump memory to 1 GiB on Pro for heavier pages.

Once you're shipping more than two or three functions, the patterns repeat. The CLI gets faster than the portal. Workspace secrets save you from pasting the same key into ten panels. Templates become your reference implementation for "how does a webhook handler that does X look on FlowEngine?"

Wrapping Up

That's every option in the product as of today. The list will grow (more runtimes, more triggers, more templates), but the shape stays the same: write a handler, push it, get a URL, watch the executions and logs as the requests come in.

Sign up for FlowEngine and you'll touch every panel in this guide within a week of normal use.