DevCloud

Mon, 01 Jan 0001 00:00:00 +0000

Architecture

DevCloud is a single Go binary that serves cloud provider APIs locally. It targets AWS today; the seams that let a second CSP join are described at the bottom.

Request Flow

Client (boto3 / AWS CLI / Terraform / CDK)
 │
 ▼
API Gateway (port 4747)
 │
 ├─ Middleware Chain
 │ ├─ ErrorRecovery (panic recovery)
 │ ├─ BodyLimit (request size limiting)
 │ ├─ CORS (cross-origin handling)
 │ ├─ RequestID (X-Amz-Request-Id)
 │ ├─ RequestLogger (structured logging)
 │ ├─ Identity (auth.Adapter → claimed identity on the request context)
 │ └─ LogCollector (admin API live logs)
 │
 ├─ Route: /devcloud/api/* → Admin API
 │
 ▼
Protocol Detector
 │
 ├─ X-Amz-Target header present → JSON protocol
 ├─ x-www-form-urlencoded + Action= → Query protocol
 ├─ SigV4 credential scope → REST-JSON (signing name picks the service)
 └─ Default → REST-XML (S3)
 │
 ▼
Service Router → Plugin Registry → ServicePlugin.HandleRequest()
 │
 ├─ returns plugin.ErrUnhandledOp → generic CRUD engine (docs/crud-engine.md)
 │
 ▼
Storage Backend → Response Serializer → HTTP Response

Plugin System

Every service implements ServicePlugin:

Mon, 01 Jan 0001 00:00:00 +0000

Compatibility Policy

What DevCloud v1.0 promises, and what it deliberately does not.

This covers the surfaces you touch as a user: the config file, the environment, the CLI, the admin API, and the AWS wire protocol. For the in-tree Go contract that service implementations are written against, see plugin-api.md.

Versions follow Semantic Versioning. “Across 1.x” means every release from v1.0.0 up to but not including v2.0.0.

Guaranteed across 1.x

Configuration file

These keys keep their name, type and meaning. New keys may be added; existing ones are not removed or repurposed. Defined in internal/config/config.go.

Mon, 01 Jan 0001 00:00:00 +0000

Configuration

Configuration is optional. With no flags, devcloud enables every registered service on port 4747 and stores data under ./data/<service>/. The defaults are compiled into the binary from internal/config/default.yaml.

Config is resolved in this order, and environment beats YAML beats embedded default:

--config <path> — explicit; the file must exist
./devcloud.yaml in the working directory — auto-detected
Embedded defaults

Environment variables

Variable	Overrides	Description
`DEVCLOUD_PORT`	`server.port`	HTTP server port
`DEVCLOUD_SERVICES`	`services.*.enabled`	Comma-separated service list, or a tier shortcut
`DEVCLOUD_DATA_DIR`	`services.*.data_dir`	Base data directory for all services

`DEVCLOUD_SERVICES`

When set, it names the running set outright: only the listed services start, regardless of their enabled setting, and a service the services block omits entirely still starts if you name it here (the block still supplies its data_dir). When unset, each service uses its YAML enabled value. An unknown tierN token is treated as a literal service name and logged as a warning.

Mon, 01 Jan 0001 00:00:00 +0000

Contributing

Prerequisites

Go 1.26+
Python 3.10+ with pip (compatibility tests)
Docker (optional — Lambda runtime and integration tests)
pre-commit (optional but recommended)
Hugo extended 0.165+ (optional — only to preview this documentation as a site)

No C toolchain and no SQLite headers: the SQLite driver is pure Go, which is why everything here builds with CGO_ENABLED=0.

Setup

git clone https://github.com/skyoo2003/devcloud.git
cd devcloud
make build # builds dist/devcloud and dist/codegen
make run # starts the server on port 4747

Make Targets

Command	Description
`make build`	Build both binaries into `dist/` — `devcloud` and `codegen`
`make run`	Run the server from source (`go run ./cmd/devcloud`)
`make test`	Run all Go tests with `CGO_ENABLED=0` and `-v`
`make test-compat`	Install `tests/compatibility/requirements.txt` and run the boto3 suite
`make codegen`	Regenerate `internal/generated/` from every model in `smithy-models/`
`make codegen-s3`	Same, restricted to S3 — fast loop while editing templates
`make docker-build`	Build the image from `docker/Dockerfile` as `devcloud/devcloud`
`make docker-run`	Run that image on port 4747 with `./data` mounted
`make docs-serve`	Preview this documentation locally with Hugo
`make docs-build`	Build the documentation site and check every internal link
`make clean`	Delete `dist/`, `data/`, and the Hugo output in `public/` and `resources/`
`make changelog VERSION=vX.Y.Z`	Batch and merge Changie fragments; `VERSION` is required
`make stats`	Print registered service and operation counts

Testing

make test # Go tests, CGO_ENABLED=0 — the same mode releases ship
make test-compat # Python/boto3 suite in tests/compatibility/

You do not need a server running first. The devcloud_server session fixture in conftest.py starts one via go run, on a free port, against a temporary data directory it removes afterwards. Three environment variables change that:

Mon, 01 Jan 0001 00:00:00 +0000

Coverage

Three numbers describe DevCloud’s AWS surface, and they mean different things. The service count alone is not a capability claim, so this page never states it alone.

Number	What it means	Today
Registered	The gateway routes the service, so the call reaches DevCloud instead of real AWS.	205
Serving ≥1 operation	At least one operation returns a real, store-backed answer.	201
Registered-only	Routed, but every operation declines with a clean AWS error.	4
Compatibility-tested	A boto3 test exercises the service in CI and passes.	203

Per operation, from the fidelity manifest:

Mon, 01 Jan 0001 00:00:00 +0000

Generic CRUD Fallback Engine

DevCloud auto-serves standard CRUD-shaped operations that a service’s hand-written provider has not implemented, using a generic engine driven by the Smithy models. This is what lets the long tail respond to SDK calls without hand-coding each one.

Fidelity is deliberately “plausible, not faithful.” Responses are store-backed and echo the caller’s input plus synthesized ids and ARNs, so SDKs round-trip create → get → list → delete. There is no validation, cross-resource integrity, pagination correctness, or business logic. Treat engine-served operations as scaffolding for local wiring, not as behavioural parity.

Mon, 01 Jan 0001 00:00:00 +0000

Demand for unregistered services

The evidence behind DevCloud’s coverage target. Sampled 2026-09-05; re-derive with python3 scripts/demand_rank.py.

What this measures

DevCloud has no usage telemetry, so this page does not measure what its users ask for. It measures revealed demand: how many of three independent projects have already built each AWS service DevCloud does not register. Each serves a population DevCloud names as its own, and each only adds a service when somebody asks.

Mon, 01 Jan 0001 00:00:00 +0000

FAQ

General

What is DevCloud? A local, API-compatible cloud environment for inner-loop development. Run it on your laptop or in CI and point your AWS SDKs, CLI or Terraform at it instead of real AWS.

Is it a production service? No. It is a local development tool, not designed or tested for production, and should not be exposed to untrusted networks. See SECURITY.md.

How is it different from other local cloud emulators? DevCloud positions itself as an on-ramp rather than a replacement:

Mon, 01 Jan 0001 00:00:00 +0000

Fidelity Manifest

Not every operation is served the same way. The fidelity manifest answers, per operation, how much you can trust this call — so a green response never leaves you guessing whether DevCloud implemented the operation or made something plausible up.

It is generated, never hand-written: make codegen derives it from the in-tree Smithy models, the CRUD registry, and each provider’s dispatch code. Current totals are published in coverage.md.

Tiers

Tier	Meaning	Trust it for
`hand-verified`	The service’s provider implements the operation explicitly.	Behaviour, not just shape. Covered by the boto3 suite where tests exist.
`auto-crud`	Served by the generic CRUD engine: store-backed, plausible responses with no validation, business logic, or cross-resource integrity.	Wiring your SDK up and round-tripping create → get → list → delete. Nothing else.
`unimplemented`	Not served — the call fails instead of inventing a success.	Knowing early that DevCloud will not serve this call.

hand-verified always wins: the CRUD engine is reached only when a provider’s dispatch falls through, so a hand-written implementation is never shadowed.

Mon, 01 Jan 0001 00:00:00 +0000

Getting Started

Run with Docker (recommended)

docker run -p 4747:4747 ghcr.io/skyoo2003/devcloud:latest

To persist data across restarts, mount a volume:

docker run -p 4747:4747 -v $(pwd)/data:/app/data ghcr.io/skyoo2003/devcloud:latest

Docker Compose (development)

docker compose -f docker/docker-compose.yml up

Builds the image from source and starts the Go server on port 4747 with ./data mounted. It runs a subset, not everything — docker-compose.yml sets DEVCLOUD_SERVICES=s3,sqs,dynamodb,iam,sts,lambda. Edit that line, or see Configuration, to run more.

Build from source

Recommended only for contributors — see contributing.md for full prerequisites and workflow.

Mon, 01 Jan 0001 00:00:00 +0000

ServicePlugin API

The stable contract every DevCloud service implements. As of v1.0 this is a public API — see API stability.

The interface and registry live in internal/plugin/. Plugins are compiled in-tree and register themselves at startup; there is no dynamic loading. (That is why the package is under internal/ — it is imported by DevCloud’s own binaries, not by third-party modules.)

The interface

type ServicePlugin interface {
 ServiceID() string
 ServiceName() string
 Protocol() ProtocolType
 Init(config PluginConfig) error
 Shutdown(ctx context.Context) error
 HandleRequest(ctx context.Context, op string, req *http.Request) (*Response, error)
 ListResources(ctx context.Context) ([]Resource, error)
}

Method	Contract
`ServiceID()`	Stable lowercase identifier, e.g. `"s3"`. Must equal the key the plugin is registered under — the gateway routes by it. Constant; safe before `Init`.
`ServiceName()`	Human-readable name for logs and the admin API. Non-empty, constant, safe before `Init`.
`Protocol()`	One of the `ProtocolType` constants. Constant; safe before `Init`.
`Init(config)`	Called once at startup before any request. Open stores, read `config.Options`. A non-nil error aborts startup (services in the fixed init order) or skips the service (others).
`Shutdown(ctx)`	Called once at graceful shutdown, 15s budget. Flush and close. Idempotent-friendly.
`HandleRequest(ctx, op, req)`	Handle one API call. See operation names — `op` may be `""` for REST protocols, in which case derive it yourself. Return a `Response`; return a Go `error` only for unexpected internal failures (the gateway wraps those as `500 InternalError`). Model AWS errors as a normal `Response`.**
`ListResources(ctx)`	The resources this service currently holds, for the admin API. May be empty.

These invariants are enforced for every registered service by TestServicePluginConformance.

Mon, 01 Jan 0001 00:00:00 +0000

Roadmap

DevCloud aims to be a local development companion for cloud-native apps across every major CSP — not a production replacement, but an on-ramp that lets you iterate without cloud bills and deploy to your target CSP with confidence. It gets there in phases, to keep scope, architectural complexity and community expectations manageable.

Guiding principles

Local-first, cost-free — no cloud charges for inner-loop development.
On-ramp, not replacement — DevCloud helps you land on a CSP, not avoid it.
API-compatible, not behaviour-perfect — SDK compatibility over edge-case parity.
Community-owned — the scope is too large for one maintainer, so the plugin architecture and contributor experience are first-class.
Trademark-respectful — see TRADEMARKS.md.

Phase 1 — AWS depth and stabilization (complete, shipped as v1.0)

Mature the already-broad AWS surface into a stable, well-tested v1.0.

Mon, 01 Jan 0001 00:00:00 +0000

Services Matrix

Which AWS services DevCloud serves, and how deeply.

Counts live in coverage.md — it is the only page that publishes them, and CI fails if its figures and the binary disagree. This page describes the shape of the surface instead.

How to look up one service

Per-operation depth is declared by the generated fidelity manifest, not by a hand-maintained table. Ask it directly (requires admin.enabled: true):

curl -s 'localhost:4747/devcloud/api/fidelity?service=s3'

Tier	What it means
`hand-verified`	The service’s provider implements the operation explicitly.
`auto-crud`	Served by the CRUD engine — store-backed and plausible, not faithful.
`unimplemented`	Refused with an AWS-shaped error. Never a fabricated success.

Depth by group

Group	Services	Depth
Core	S3, SQS, DynamoDB, Lambda, IAM, STS	Hand-written throughout; the deepest boto3 coverage
Integration	SNS, EventBridge, CloudWatch, CW Logs, KMS, Secrets Manager, SSM, ECR, CloudFormation	Hand-written common operations, plus the cross-service wiring below
Extended	EC2, ECS, EKS, Route53, ACM, RDS, Kinesis, Firehose, SFN, Bedrock, and the rest of the registered set	Common operations hand-written; the long tail is engine-served or declines cleanly

The tier1 / tier2 / tier3 tokens accepted by DEVCLOUD_SERVICES are a startup grouping, not a depth claim — see configuration.md for their exact contents.

Mon, 01 Jan 0001 00:00:00 +0000

DynamoDB

Overview

DevCloud DynamoDB uses BadgerDB as its embedded key-value storage backend. Table metadata is kept in an in-memory index (protected by RWMutex), while items are persisted in BadgerDB with composite keys (_item/{table}#{partitionKey}#{sortKey}).

Supported attribute types: S (String), N (Number), B (Binary), BOOL, NULL, L (List), M (Map).

Supported APIs

Operation	Description
CreateTable	Create table with partition key (HASH) and optional sort key (RANGE)
DeleteTable	Delete table and all its items
ListTables	List all table names
PutItem	Insert or overwrite an item
GetItem	Retrieve an item by primary key
DeleteItem	Delete an item by primary key
Query	Query items by partition key
Scan	Full table scan

boto3 Examples

Create a table and write items

import boto3

dynamodb = boto3.client(
 "dynamodb",
 endpoint_url="http://localhost:4747",
 aws_access_key_id="test",
 aws_secret_access_key="test",
 region_name="us-east-1",
)

# Create table
dynamodb.create_table(
 TableName="users",
 KeySchema=[
 {"AttributeName": "pk", "KeyType": "HASH"},
 {"AttributeName": "sk", "KeyType": "RANGE"},
 ],
 AttributeDefinitions=[
 {"AttributeName": "pk", "AttributeType": "S"},
 {"AttributeName": "sk", "AttributeType": "S"},
 ],
 BillingMode="PAY_PER_REQUEST",
)

# Put item
dynamodb.put_item(
 TableName="users",
 Item={
 "pk": {"S": "user#123"},
 "sk": {"S": "profile"},
 "name": {"S": "Alice"},
 "age": {"N": "30"},
 },
)

# Get item
response = dynamodb.get_item(
 TableName="users",
 Key={"pk": {"S": "user#123"}, "sk": {"S": "profile"}},
)
print(response["Item"])

Query and scan

# Query by partition key
response = dynamodb.query(
 TableName="users",
 KeyConditionExpression="pk = :pk",
 ExpressionAttributeValues={":pk": {"S": "user#123"}},
)
for item in response["Items"]:
 print(item)

# Full table scan
response = dynamodb.scan(TableName="users")
for item in response["Items"]:
 print(item)

AWS CLI Examples

# Create table
aws --endpoint-url http://localhost:4747 dynamodb create-table \
 --table-name my-table \
 --key-schema AttributeName=pk,KeyType=HASH \
 --attribute-definitions AttributeName=pk,AttributeType=S \
 --billing-mode PAY_PER_REQUEST

# Put item
aws --endpoint-url http://localhost:4747 dynamodb put-item \
 --table-name my-table \
 --item '{"pk": {"S": "key1"}, "data": {"S": "value1"}}'

# Get item
aws --endpoint-url http://localhost:4747 dynamodb get-item \
 --table-name my-table \
 --key '{"pk": {"S": "key1"}}'

Known Limitations

No UpdateItem (use PutItem to overwrite entire item)
No batch operations (BatchGetItem, BatchWriteItem)
No transactions (TransactGetItems, TransactWriteItems)
No secondary indexes (GSI/LSI)
No DynamoDB Streams
No advanced filter expressions on Query/Scan
No projection expressions
No conditional writes (ConditionExpression)
No TTL

Mon, 01 Jan 0001 00:00:00 +0000

IAM / STS

Overview

DevCloud IAM and STS share a single SQLite database (WAL mode). IAM manages users, roles, and access keys. STS generates temporary credentials and caller identity information.

Both services use the Query protocol (form-encoded requests, XML responses).

Supported IAM APIs

Operation	Description
CreateUser	Create an IAM user
ListUsers	List all IAM users
CreateRole	Create an IAM role with assume role policy document
ListRoles	List all IAM roles
AttachRolePolicy	Attach a managed policy ARN to a role
CreateAccessKey	Generate an access key pair for a user

Supported STS APIs

Operation	Description
GetCallerIdentity	Return account ID, ARN, and user ID
AssumeRole	Generate temporary credentials (ASIA-prefixed keys, 1-hour expiry)
GetSessionToken	Generate MFA-backed session credentials

boto3 Examples

IAM: Create users and roles

import boto3

iam = boto3.client(
 "iam",
 endpoint_url="http://localhost:4747",
 aws_access_key_id="test",
 aws_secret_access_key="test",
 region_name="us-east-1",
)

# Create user
iam.create_user(UserName="testuser")

# Create access key for user
keys = iam.create_access_key(UserName="testuser")
print(keys["AccessKey"]["AccessKeyId"])
print(keys["AccessKey"]["SecretAccessKey"])

# Create role
iam.create_role(
 RoleName="lambda-role",
 AssumeRolePolicyDocument='{"Version":"2012-10-17","Statement":[]}',
)

# List users and roles
for user in iam.list_users()["Users"]:
 print(user["UserName"])
for role in iam.list_roles()["Roles"]:
 print(role["RoleName"])

STS: Get caller identity and assume role

sts = boto3.client(
 "sts",
 endpoint_url="http://localhost:4747",
 aws_access_key_id="test",
 aws_secret_access_key="test",
 region_name="us-east-1",
)

# Get caller identity
identity = sts.get_caller_identity()
print(identity["Account"]) # 000000000000
print(identity["Arn"])

# Assume role
response = sts.assume_role(
 RoleArn="arn:aws:iam::000000000000:role/lambda-role",
 RoleSessionName="my-session",
)
creds = response["Credentials"]
print(creds["AccessKeyId"]) # ASIA-prefixed
print(creds["SecretAccessKey"])
print(creds["SessionToken"])
print(creds["Expiration"]) # 1 hour from now

AWS CLI Examples

# Create user
aws --endpoint-url http://localhost:4747 iam create-user --user-name testuser

# Create access key
aws --endpoint-url http://localhost:4747 iam create-access-key --user-name testuser

# Get caller identity
aws --endpoint-url http://localhost:4747 sts get-caller-identity

# Assume role
aws --endpoint-url http://localhost:4747 sts assume-role \
 --role-arn arn:aws:iam::000000000000:role/my-role \
 --role-session-name my-session

Known Limitations

IAM:

Mon, 01 Jan 0001 00:00:00 +0000

Lambda

Overview

DevCloud Lambda stores function metadata in SQLite and function code (ZIP files) on the filesystem. Function registration and management are fully supported, but code execution is currently a stub — invoking a function returns a placeholder response instead of running the actual code.

Supported APIs

Operation	Description
CreateFunction	Create function with base64-encoded ZIP code
ListFunctions	List all functions in the account
GetFunction	Get function metadata and code location
DeleteFunction	Delete a function
UpdateFunctionCode	Update function code ZIP
Invoke	Invoke function (stub — returns placeholder response)

boto3 Examples

Create and manage functions

import boto3
import zipfile
import io
import base64

lambda_client = boto3.client(
 "lambda",
 endpoint_url="http://localhost:4747",
 aws_access_key_id="test",
 aws_secret_access_key="test",
 region_name="us-east-1",
)

# Create a ZIP file with handler code
zip_buffer = io.BytesIO()
with zipfile.ZipFile(zip_buffer, "w") as zf:
 zf.writestr("index.py", 'def handler(event, context): return {"statusCode": 200}')
zip_buffer.seek(0)

# Create function
lambda_client.create_function(
 FunctionName="my-func",
 Runtime="python3.12",
 Handler="index.handler",
 Role="arn:aws:iam::000000000000:role/lambda-role",
 Code={"ZipFile": zip_buffer.read()},
)

# List functions
response = lambda_client.list_functions()
for fn in response["Functions"]:
 print(fn["FunctionName"], fn["Runtime"])

# Get function details
response = lambda_client.get_function(FunctionName="my-func")
print(response["Configuration"]["FunctionArn"])

Invoke function (stub)

import json

response = lambda_client.invoke(FunctionName="my-func", Payload=json.dumps({"key": "value"}))
print(json.loads(response["Payload"].read()))
# {"statusCode": 200, "body": "Lambda invoke requires Docker runtime"}

AWS CLI Examples

# Create function
aws --endpoint-url http://localhost:4747 lambda create-function \
 --function-name my-func \
 --runtime python3.12 \
 --handler index.handler \
 --role arn:aws:iam::000000000000:role/role \
 --zip-file fileb://code.zip

# List functions
aws --endpoint-url http://localhost:4747 lambda list-functions

# Invoke (returns stub response)
aws --endpoint-url http://localhost:4747 lambda invoke \
 --function-name my-func output.json

Known Limitations

No code execution — Invoke returns a placeholder response. Docker runtime integration is planned but not yet implemented.
No layers
No aliases or versions
No event source mappings
No concurrency controls
No function URLs
No resource-based policies
No environment variables support

Mon, 01 Jan 0001 00:00:00 +0000

S3 (Simple Storage Service)

Overview

DevCloud S3 provides basic object storage using the filesystem for object data and SQLite for metadata. Objects are stored as files on disk; bucket and object metadata (names, sizes, ETags, content types, timestamps) are tracked in a SQLite database with WAL mode enabled.

Supported APIs

Operation	Description
ListBuckets	List all buckets in the account
CreateBucket	Create a new bucket
DeleteBucket	Delete an empty bucket
ListObjects	List objects in a bucket (supports prefix filtering)
PutObject	Upload an object (computes MD5 ETag)
GetObject	Download an object with metadata headers
HeadObject	Retrieve object metadata without body
DeleteObject	Delete an object from a bucket

boto3 Examples

Create a bucket and upload an object

import boto3

s3 = boto3.client(
 "s3",
 endpoint_url="http://localhost:4747",
 aws_access_key_id="test",
 aws_secret_access_key="test",
 region_name="us-east-1",
)

# Create bucket
s3.create_bucket(Bucket="my-bucket")

# Upload object
s3.put_object(Bucket="my-bucket", Key="hello.txt", Body=b"Hello, DevCloud!")

# Download object
response = s3.get_object(Bucket="my-bucket", Key="hello.txt")
print(response["Body"].read().decode()) # Hello, DevCloud!

List buckets and objects

# List all buckets
buckets = s3.list_buckets()
for b in buckets["Buckets"]:
 print(b["Name"])

# List objects in a bucket
objects = s3.list_objects(Bucket="my-bucket", Prefix="hello")
for obj in objects.get("Contents", []):
 print(obj["Key"], obj["Size"])

AWS CLI Examples

# Create bucket
aws --endpoint-url http://localhost:4747 s3 mb s3://my-bucket

# Upload file
aws --endpoint-url http://localhost:4747 s3 cp file.txt s3://my-bucket/

# List objects
aws --endpoint-url http://localhost:4747 s3 ls s3://my-bucket/

# Download file
aws --endpoint-url http://localhost:4747 s3 cp s3://my-bucket/file.txt ./downloaded.txt

Known Limitations

No multipart upload support (CreateMultipartUpload, UploadPart, CompleteMultipartUpload)
No object versioning or object lock
No ACL or bucket policy management
No encryption (SSE-S3, SSE-KMS)
No CORS configuration
No lifecycle policies
No replication
No presigned URLs
Single account model (account ID: 000000000000)

Mon, 01 Jan 0001 00:00:00 +0000

SQS (Simple Queue Service)

Overview

DevCloud SQS provides in-memory message queues. Queues are stored in memory with thread-safe access (sync.RWMutex). Data is not persisted — all queues and messages are lost on server restart.

SQS supports dual protocol: legacy Query protocol (form-encoded with XML responses) and modern JSON 1.0 protocol (used by boto3 1.42+). The protocol is auto-detected based on the Content-Type header.

Supported APIs

All 23 SQS operations are handled over the JSON 1.0 protocol.

Mon, 01 Jan 0001 00:00:00 +0000

Troubleshooting

If your problem isn’t here, see SUPPORT.md for where to ask.

Build and startup

go: module github.com/skyoo2003/devcloud: Go 1.26 required Upgrade Go to 1.26+ (go version, then go.dev/dl).

bind: address already in use on port 4747 Something else holds the port. Change DevCloud’s:

# devcloud.yaml
server:
 port: 4100

Or map a different host port: docker run -p 4100:4747 ….

Server starts but clients get connection refused Check it is actually listening — any request works, DevCloud has no health endpoint: