Deploy an HTTP Function on Raff: Step-by-Step

Raff Functions can expose a standard HTTP handler through a live HTTPS URL without requiring a Raff-specific SDK or handler format. This tutorial uses Node.js because the built-in http module keeps the example portable and dependency-free.

This workflow was verified against the live Raff Functions product contract on September 21, 2026. It is not labeled "Tested on Raff" because this article was not produced from an independently recorded console deployment with engineer screenshots.

What you will deploy

You will deploy a small HTTP function that:

• responds on /;
• returns JSON;
• reads a name query parameter;
• uses Node.js standard http;
• runs behind the HTTPS Function URL Raff assigns after deployment.

Prerequisites: Node.js installed locally, a Raff account with Functions access, and permission to create and delete a test function. See the Raff Functions product page linked in the introduction for current deployment options and pricing.

This example intentionally has no authentication, webhook signature verification, or route-level rate limiting. For a public production endpoint, implement those controls using Serverless API Security before accepting sensitive requests.

The example binds to 0.0.0.0 so the managed runtime can route requests. During local testing, use a trusted development environment and block inbound access to port 3000; do not expose the local test server publicly.

Create a file named server.js:

const http = require("http");
const { URL } = require("url");

const server = http.createServer((req, res) => {
  const url = new URL(req.url, "http://localhost");
  const name = url.searchParams.get("name") || "world";

  res.writeHead(200, {
    "Content-Type": "application/json",
  });

  res.end(
    JSON.stringify({
      message: `Hello, ${name}!`,
      runtime: "node",
    })
  );
});

const port = process.env.PORT || 3000;

server.listen(port, "0.0.0.0", () => {
  console.log(`Listening on port ${port}`);
});

This is a standard Node.js HTTP server. It does not import a Raff-specific runtime package.

Step 1 — Verify the function locally

Run:

node server.js

In a second terminal:

curl "http://localhost:3000/?name=Raff"

Expected response:

{"message":"Hello, Raff!","runtime":"node"}

Verification

Confirm that:

• Node starts without an exception;
• port 3000 is listening;
• the endpoint returns HTTP 200;
• the JSON changes when you change the name parameter.

If the code does not work locally, fix that before deploying.

Step 2 — Create a new Raff Function

Open the Raff dashboard and go to Functions.

Choose New function.

The current Functions flow supports creating a function from a template, uploading or pasting code, or importing an AWS Lambda. For this tutorial, use the normal code path rather than Lambda migration.

Give the function a short name such as:

hello-http

Raff assigns the final Function URL and adds a short random suffix so names do not collide across accounts.

Verification

Before deploying, confirm that the create screen shows:

• your function name;
• a supported runtime;
• memory;
• timeout;
• scaling settings.

The current product defaults shown by Raff are 256 MB memory, a 5-minute timeout, and scaling from 0 to 10. You can change these later, so do not over-tune a hello-world endpoint.

Step 3 — Add the Node.js handler

Select the Node.js runtime or use the in-dashboard editor/upload flow.

Add the server.js file from Step 1.

Raff Functions is designed around standard handlers. For Node.js, that means you can use normal Node HTTP code rather than a proprietary event object.

If the deployment flow asks for an entry point, use the project entry point that starts server.js.

Verification

Review the code in the dashboard and confirm that:

• the file is present;
• the runtime is Node.js;
• there are no Raff-specific imports;
• the application listens on process.env.PORT when provided.

Step 4 — Keep the first deployment simple

For this endpoint, keep the default memory, timeout, and scale-to-zero behavior unless you have a reason to change them.

A small HTTP handler usually does not need a long timeout or warm capacity. The goal of the first deployment is to verify the request path, not benchmark production settings.

Raff Functions currently supports scale-to-zero, autoscaling, optional warm instances, and configurable memory and timeout settings.

Verification

Confirm that:

• minimum scale remains 0 if you want scale-to-zero;
• the current cost-control settings are visible on your account;
• no unnecessary warm instance is enabled;
• the timeout is comfortably above the few milliseconds this handler needs.

Step 5 — Deploy the function

Choose Deploy.

Raff's current product flow builds standard handlers automatically, so Node.js workloads do not require a Dockerfile for a basic deployment.

Wait for the deployment to reach a live state.

The Function should receive an HTTPS URL similar in structure to:

https://hello-http-xxxxx.fn.raffusercloud.com

The suffix is assigned by the platform.

Verification

Copy the live URL and run:

curl -i "https://YOUR-FUNCTION-URL/?name=Raff"

You should see:

HTTP/2 200
content-type: application/json

with a body similar to:

{"message":"Hello, Raff!","runtime":"node"}

This verifies both deployment and the public HTTP path.

Step 6 — Test the live URL from more than one request

Run several requests:

curl "https://YOUR-FUNCTION-URL/?name=Alice"
curl "https://YOUR-FUNCTION-URL/?name=Bob"
curl "https://YOUR-FUNCTION-URL/"

Expected behavior:

• Alice returns Hello, Alice!;
• Bob returns Hello, Bob!;
• no query parameter returns Hello, world!.

Verification

Check that every request returns HTTP 200 and valid JSON.

This matters because a successful deployment alone does not prove the handler is parsing requests correctly.

Step 7 — Check invocation logs

Open the function's logs in the Raff dashboard.

Raff Functions currently includes live log tailing and per-invocation observability. Recent requests can be correlated with their logs.

Your code already logs:

Listening on port 3000

For a production endpoint, add structured application logs for failures and important state transitions rather than logging secrets or full sensitive request bodies.

Verification

Send another request to the live URL and confirm that the dashboard shows recent invocation activity.

Also check that the function's request count and error rate do not show an unexpected failure.

Step 8 — Add an environment variable

A function should not hard-code environment-specific configuration.

Add an environment variable in the function configuration:

APP_ENV=production

Then update the response:

res.end(
  JSON.stringify({
    message: `Hello, ${name}!`,
    runtime: "node",
    environment: process.env.APP_ENV || "development",
  })
);

Redeploy the function.

Verification

Run:

curl "https://YOUR-FUNCTION-URL/?name=Raff"

Expected body:

{
  "message": "Hello, Raff!",
  "runtime": "node",
  "environment": "production"
}

For actual secrets, use masked-secret or scoped-binding features rather than placing credentials directly in source code.

Step 9 — Verify scale-to-zero and cost controls

Raff Functions pricing, metering dimensions, included usage, and account cost controls can change. Check the current Functions pricing and dashboard settings before making cost-sensitive decisions.

For a low-traffic HTTP endpoint, scale-to-zero is usually the sensible starting point because idle instances should not remain allocated without a latency requirement.

Verification

Check the function configuration and confirm:

• minimum scale is 0 unless you intentionally changed it;
• the intended cost-control settings are configured;
• memory and timeout match the workload;
• no secret or credential is stored in source code.

For latency-sensitive production APIs, test cold-start behavior with your actual code and dependencies before enabling warm instances.

Step 10 — Run the final end-to-end verification

Run:

curl --fail-with-body -sS -i "https://YOUR-FUNCTION-URL/?name=FinalCheck"

Then verify all of the following:

• the request returns HTTP 200;
• JSON is valid;
• the query parameter is reflected correctly;
• the environment value is present;
• the invocation appears in Raff logs;
• the function has no unexpected errors;
• the intended cost-control settings remain configured;
• scale-to-zero remains configured if intended.

Your first HTTP Function is now deployed and reachable through a live HTTPS URL.

When an HTTP Function is a good fit

Use a Function when one request maps to a bounded unit of work, such as:

• webhook receivers;
• small JSON APIs;
• image or document processing requests;
• callbacks from another service;
• asynchronous job submission;
• internal utility endpoints.

Use a persistent App Platform service or VM when the application depends on a continuously running process, many tightly coupled routes, long-lived connections, local process state, or a full operating-system environment.

For the architecture decision, see Serverless API Endpoint vs App Platform and Serverless Functions vs VMs.

Cleanup

If this was only a test deployment:

1. remove any temporary environment variables;
2. delete or disable the Function in the dashboard;
3. confirm the live URL no longer serves the test endpoint;
4. review recent usage before removing the test project.

Do not leave sample endpoints publicly reachable when they are no longer needed.

Conclusion

This tutorial shows a portable Node.js HTTP handler deployed through Raff Functions with a live HTTPS URL, log inspection, environment variables, and scale-to-zero configuration. For public production endpoints, add request authentication, input validation, rate limiting, and appropriate secret handling. Compare Functions with Raff Apps and VMs based on the runtime and operating model your workload needs; the linked architecture guides explain the differences.