{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreiclbwq6lkm23m73pfhesq7nsyz4v7oj5ymmezrdmum2bzq3i6oiey",
"uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mqe7mksco7o2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreigzfsra65m7jkd3bzlepjlyvogt7mnsjd7hsni6oylsxhhnuxxgvm"
},
"mimeType": "image/webp",
"size": 563360
},
"path": "/zintrustjs/connect-redis-postgres-and-mysql-to-serverless-apps-over-https-cg",
"publishedAt": "2026-07-11T07:28:49.000Z",
"site": "https://dev.to",
"tags": [
"serverless",
"database",
"redis",
"webdev",
"https://zedgi.app",
"https://zedgi.app/docs/",
"@zedgi"
],
"textContent": "Serverless and edge runtimes are great until your app needs a normal TCP database connection.\n\nZedGi works with:\n\n * **TypeScript / JavaScript SDK** : Cloudflare Workers, Vercel Edge, Deno, Bun, Node.js, AWS Lambda, and any runtime with `fetch`.\n * **Python SDK** : FastAPI, Flask, Django, scripts, background jobs, AWS Lambda, and other Python services.\n * **Raw HTTP API** : curl, Go, PHP, Ruby, Java, Rust, no-code tools, internal platforms, and any environment that can send signed HTTPS requests.\n\n\n\nCloudflare Workers, Vercel Edge, Deno Deploy, and many other HTTP-first runtimes do not let you open raw TCP sockets directly. That creates an awkward choice:\n\n * Move to a provider-specific serverless database.\n * Add a custom backend just to proxy database calls.\n * Expose database ports and manage networking yourself.\n * Give up on running that part of the app at the edge.\n\n\n\nZedGi is built for the other path: keep your own Redis, Postgres, or MySQL database, but call it from any HTTP runtime.\n\n## What is ZedGi?\n\nZedGi is a TCP-to-HTTP proxy for Redis, Postgres, and MySQL.\n\nYou register a database service once, then your app sends signed HTTPS requests to your ZedGi endpoint. ZedGi authenticates the request, routes it to a bridge node, opens the real TCP connection, runs the command or query, and returns JSON.\n\nThe basic flow looks like this:\n\n\n\n Your app\n -> HTTPS request\n -> ZedGi gateway\n -> bridge proxy\n -> Redis / Postgres / MySQL\n\n\nThat means code running in an edge or serverless runtime can still talk to traditional TCP databases without managing VPNs, public database ports, or long-lived connection pools in your function.\n\n## Why developers use it\n\n### Use the database you already have\n\nZedGi is not a hosted Redis-only, Postgres-only, or MySQL-only product.\n\nIt is designed for teams that already have a database somewhere and want to make it reachable from HTTP-only runtimes.\n\nSupported services:\n\n * Redis\n * Postgres\n * MySQL\n * Custom TCP services (on request)\n\n\n\n### Works from any HTTP runtime\n\nIf your runtime can make an HTTPS request, it can call ZedGi.\n\nThat includes:\n\n * Cloudflare Workers\n * Vercel Edge Functions\n * AWS Lambda\n * Deno\n * Bun\n * Node.js\n * Any environment with `fetch`\n\n\n\n### Credentials are not stored in ZedGi\n\nDatabase credentials are supplied at call time by your application.\n\nThe client encrypts the credential payload before it leaves your app. ZedGi stores service metadata like host, port, service type, and optional caller IP allowlist, but not your plaintext database password.\n\n## Example: Redis from an edge runtime\n\nInstall the client:\n\n\n\n npm install @zedgi/zedgi-client\n\n\nThen call Redis over HTTPS:\n\n\n\n import { createZedgiClient } from \"@zedgi/zedgi-client\";\n\n const zedgi = createZedgiClient({\n url: \"https://your-subdomain.zedgi.app\",\n key: process.env.ZEDGI_KEY!,\n });\n\n const redis = zedgi.redis({\n credential: {\n password: process.env.REDIS_PASSWORD,\n db: 0,\n },\n });\n\n await redis.set(\"edge:hello\", \"world\");\n const value = await redis.get(\"edge:hello\");\n\n console.log(value); // \"world\"\n\n\nThe same pattern works for Postgres and MySQL.\n\n## Example: Postgres query\n\n\n const pg = zedgi.postgres({\n credential: {\n user: process.env.PG_USER!,\n password: process.env.PG_PASSWORD!,\n database: process.env.PG_DATABASE!,\n ssl: true,\n },\n });\n\n const { rows } = await pg.query(\n \"select id, email from users where id = $1\",\n [userId]\n );\n\n\n## Example: MySQL query\n\n\n const mysql = zedgi.mysql({\n credential: {\n user: process.env.MYSQL_USER!,\n password: process.env.MYSQL_PASSWORD!,\n database: process.env.MYSQL_DATABASE!,\n },\n });\n\n const [rows] = await mysql.query(\n \"select id, email from users where id = ?\",\n [userId]\n );\n\n\n## What about security?\n\nZedGi uses a few layers:\n\n * API keys identify the caller.\n * Requests are signed to prevent tampering and replay.\n * Database credentials are encrypted client-side.\n * Optional caller IP allowlisting can restrict which source IP may use a service.\n * The proxy bridge only decrypts credentials transiently to open the TCP connection.\n\n\n\nThe goal is simple: your edge app can call your database, but ZedGi does not become a place where plaintext database passwords sit around.\n\n## When ZedGi is useful\n\nZedGi is a good fit when:\n\n * You want Cloudflare Workers or edge functions to talk to your existing database.\n * You do not want to migrate to a vendor-specific serverless database.\n * You need Redis, Postgres, and MySQL behind one HTTPS access layer.\n * You have a custom TCP service you want to expose through the same HTTPS proxy model.\n * You want a dashboard for API keys, services, usage, and billing.\n * You need to keep database ports private.\n\n\n\nIt is especially useful for internal tools, SaaS dashboards, lightweight APIs, queues, webhook workers, and jobs that need database access from serverless environments.\n\n## Try it\n\nCreate an account, register a service, generate an API key, and make your first call:\n\nš https://zedgi.app\n\nDocs:\n\nš https://zedgi.app/docs/\n\nIf you have been avoiding edge/serverless because your database still speaks TCP, ZedGi gives you a practical bridge: keep the database, call it over HTTPS.",
"title": "Connect Redis, Postgres, and MySQL to Serverless Apps Over HTTPS"
}