How to Run Serverless Functions Without AWS Lambda or Google Cloud

Serverless computing promised to eliminate infrastructure management. In practice, AWS Lambda, Google Cloud Functions, and Azure Functions still require significant ops work: IAM policies, VPC configuration, cold start optimization, logging setup, API Gateway routing, deployment pipelines, and cost forecasting.

For developers who want to run isolated functions on demand, there’s a simpler model.

What “serverless” was supposed to mean

The original promise: write a function, deploy it, call it. Pay per execution. No servers to manage. No scaling to configure. If nobody calls it, it costs nothing. If a million people call it simultaneously, it scales automatically.

That promise is partially kept by the major cloud providers. But the operational overhead is real. A typical Lambda function requires:

• An IAM role with appropriate permissions
• A function configuration (runtime, memory, timeout, environment variables)
• An API Gateway or Function URL for HTTP access
• A deployment pipeline (CloudFormation, Terraform, CDK, or Serverless Framework)
• CloudWatch log groups for observability
• VPC configuration if the function needs access to private resources

That’s not “no infrastructure.” That’s different infrastructure.

The worker model: a cleaner abstraction

A worker on Seek API is a serverless function with a different contract:

Write code → Deploy with one CLI command → Get an HTTP endpoint

No IAM. No VPC. No API Gateway. No cold start configuration. The deployment CLI handles everything:

# In your worker directory:
seek deploy

# → Building image...
# → Deploying function...
# → Running smoke test...
# → Worker live at: POST /v1/workers/my-worker/jobs
# Completed in 87 seconds

Your function is callable immediately after.

Comparison: Lambda vs Seek API worker

When to use a worker instead of Lambda

Workers are not a replacement for every Lambda use case. They’re a better fit when:

You want marketplace distribution. Lambda functions are private by default. Workers can be made public, discovered by other users, and earn revenue per run.

You’re building something others should call. Lambda doesn’t have a built-in way for external users to pay per invocation. Workers do.

You want zero DevOps. If you or your team don’t want to manage IAM roles, VPCs, and deployment infrastructure, workers remove all of that.

Your function is self-contained. Workers that accept inputs and return outputs — without needing private AWS resources — are ideal candidates.

Lambda is the right choice when you need:

• Direct access to AWS services (DynamoDB, S3, SQS)
• Event triggers from existing AWS infrastructure
• Sub-100ms cold start performance at enterprise scale
• Complex VPC routing

Calling a worker from AWS infrastructure

Workers integrate cleanly with existing infrastructure. A Lambda function can call a Seek API worker via HTTP:

import httpx
import os

def lambda_handler(event, context):
    url = event['url']
    
    # Call the worker
    response = httpx.post(
        'https://api.seek-api.com/v1/workers/website-tech-detector/jobs',
        headers={'X-Api-Key': os.environ['SEEK_API_KEY']},
        json={'url': url}
    )
    job = response.json()
    
    # Poll for result
    result = poll_until_done(job['job_uuid'])
    return result

In this pattern, Lambda handles your infrastructure events, and Seek API workers handle the heavy computation that would be complex to build and maintain yourself.

The practical tradeoff

For pure DevOps minimization: Seek API workers win. For integration with existing AWS infrastructure: Lambda wins. For distributable, monetizable functions: Seek API workers are the only option.

Most developers building automation tools, data processing pipelines, and SaaS features don’t need the full power of Lambda. They need a function that runs reliably, costs nothing when idle, and can be called via HTTP. Workers handle that cleanly.