VibeWorkflowPlatform - Moses Yebei

The Problem

Non‑technical creators need a way to stitch together AI services without writing code, yet most workflow engines require scripting or deep UI configuration. The result is a high barrier to entry and fragile “black‑box” automations that cannot be inspected or edited on the fly.

What This Does

VibeWorkflowPlatform delivers a visual canvas (see apps/web/) where each node is a pre‑built Agent (e.g., vector search, object storage). The backend lives in apps/api/ and exposes REST endpoints that the front‑end calls. Core services such as Prisma DB access (apps/api/src/modules/common/prisma.service.ts), Redis caching (apps/api/src/modules/common/redis.service.ts), and file storage (apps/api/src/modules/common/object-storage/backend/fs.ts) are centralized, while the vector store and LangChain‑based agents live in packages/ai-workspace-common/.

How It Is Wired

Execution starts in apps/api/src/main.ts → function bootstrap (line 35) which creates the NestJS server and loads the environment (apps/api/.env.example). The most‑used internal utilities are:

buildSuccessResponse (called 191 times) – formats API replies.
safeParseJSON (118 calls) – defensive JSON handling.
create (96 calls) – generic entity creation used by many services.

A typical request (e.g., creating a canvas) follows:

Controller apps/api/src/modules/canvas/canvas.controller.ts receives HTTP.
Calls CanvasService (apps/api/src/modules/canvas/canvas.service.ts), which invokes Prisma via prisma.service (77 modules import this hub).
If file assets are needed, object-storage/backend/fs.ts reads/writes the filesystem and updates staticFile rows.
For embeddings, provider.service.ts selects a model and may call external vector APIs (7 functions make outbound network calls overall).

The import graph shows 39 circular dependencies, the largest hub being prisma.service.ts (77 inbound imports, 0 outbound). Such a hub carries a high blast radius: any change to DB schema or Prisma client ripples through most API modules. The most crowded files (provider.service.ts, canvas.service.ts, misc.service.ts) each exceed 1 200 lines, indicating high cognitive load.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/VibeWorkflowPlatform
cd VibeWorkflowPlatform

# Install dependencies (pnpm is the declared manager)
pnpm install

# Build and run the API locally (Dockerfile present)
docker build -t vibe-api -f apps/api/Dockerfile .
docker run -p 3000:3000 --env-file apps/api/.env.example vibe-api

Configuration – copy apps/api/.env.example to apps/api/.env.development (contains JWT secret, Stripe key, etc.) and adjust values for your environment. The same applies to apps/web/.env.example for the front‑end.

Running the UI – build the web container similarly (apps/web/Dockerfile) and expose port 4000, then navigate to http://localhost:4000.

If you prefer a local Node run, execute the NestJS bootstrap script:

pnpm --filter api run start:dev   # inferred from package.json scripts

(Exact npm scripts are not listed; the Dockerfile is the reliable entry point.)

Real‑World Use

A content creator wants to auto‑publish blog posts to Medium after generating an outline with GPT‑4. They add two nodes: “Generate Outline” (LangChain agent) and “Publish to Medium” (HTTP tool). When the canvas runs, the API routes the request through tool.service.ts, stores the generated markdown via object-storage, and calls Medium’s API in a single transaction, all visible on the canvas for pause/review.

Code Health & Issues

Critical – Rotate credentials in apps/api/.env.development; remove the file from the repo.
High – Pin GitHub Actions to commit SHAs (.github/workflows/*).
High – Remove the committed .env and replace with an example.
High – Add a test step to CI (.github/workflows/*).
Medium – Enable Dependabot (.github/dependabot.yml).
Medium – Pin Docker base images by digest (apps/api/Dockerfile).
Medium – Add a dependency‑vulnerability scan to CI.
Medium – Add a pre‑commit secret‑scan hook.
Medium – Set persist-credentials: false on checkout (deploy-test.yml).
Medium – Run container as non‑root (apps/api/Dockerfile).

The repo includes 57 test files, but the CI workflows never invoke them. Documentation is extensive (≈ 400 Markdown files) and a license is present, yet secret‑shaped files and unpinned actions expose production risk.

The Bottom Line

The platform offers a functional visual AI workflow engine with a clear separation of front‑end canvas and back‑end services, but core modules are oversized and tightly coupled, making maintenance risky. Immediate remediation of secret handling, CI test execution, and dependency pinning is required before using this codebase in production. Suitable for teams that can invest in refactoring and security hardening.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

2,203 files

TypeScript975
TSX509
Markdown116
JSON73
SCSS70
YAML44

ReactVueTailwindDockerKubernetesLangChainVector store

Module dependencies

The 10 most depended-upon modules of 1,495, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_odules_common_prisma_service["prisma.service"] n1_apps_api_src_utils_index["index"] n2_modules_common_common_module["common.module"] n3_apps_api_src_utils_const["const"] n4_es_auth_guard_jwt_auth_guard["jwt-auth.guard"] n5_ls_decorators_user_decorator["user.decorator"] n6_rc_modules_misc_misc_service["misc.service"] n7_modules_common_redis_service["redis.service"] n8_es_provider_provider_service["provider.service"] n9_apps_api_src_utils_runtime["runtime"] n4_es_auth_guard_jwt_auth_guard --> n9_apps_api_src_utils_runtime n2_modules_common_common_module --> n0_odules_common_prisma_service n2_modules_common_common_module --> n7_modules_common_redis_service n7_modules_common_redis_service --> n9_apps_api_src_utils_runtime n6_rc_modules_misc_misc_service --> n0_odules_common_prisma_service n6_rc_modules_misc_misc_service --> n1_apps_api_src_utils_index n6_rc_modules_misc_misc_service --> n9_apps_api_src_utils_runtime n6_rc_modules_misc_misc_service --> n7_modules_common_redis_service n8_es_provider_provider_service --> n0_odules_common_prisma_service n1_apps_api_src_utils_index --> n3_apps_api_src_utils_const

Findings

LowSecret-shaped paths present; the code-health audit confirms or clears them apps/api/.env.development

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high3

medium6

low1

Rotate the credentials in the committed environment filecritical2 occurrences

apps/api/.env.development

JWT_SECRET, STRIPE_API_KEY hold generated values

These values are loaded by the application at boot, so a generated value here is a working credential for something that runs.

Fix: Rotate each named credential, remove the file from the index, and replace it with a keys-only example.

Pin third-party GitHub Actions to a commit SHAhigh4 occurrences

.github/workflows

aws-actions/configure-aws-credentials@v4, docker/setup-buildx-action@v3, docker/build-push-action@v6, pnpm/action-setup@v4

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Remove the committed .env and rotate what it holdshigh

apps/api/.env.development

A tracked .env is the most common route for a working key to reach a public clone, and it is the file the app actually loads, so the value is usually live.

Fix: git rm --cached the file, add it to .gitignore, rotate every credential it names, commit a .env.example with empty values.

Make CI invoke the test suite it hashigh54 occurrences

.github/workflows

54 test files, no test command in the 4 workflows read

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Enable Dependabot or Renovatemedium

27 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium3 occurrences

apps/api/Dockerfile

node:20.19.1-alpine3.20, surnet/alpine-wkhtmltopdf:3.20.3-0.12.6-small, node:20.19.1-alpine3.20

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Add a pre-commit secret gatemedium

a secret-shaped file is tracked and no repo-level gate is visible

Without a gate the same class of leak recurs on the next commit, so a leak finding is the symptom and this is the cause.

Fix: Add a pre-commit hook scanning staged content, and enable push protection.

Set persist-credentials: false on checkoutmedium

.github/workflows/deploy-test.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Add a non-root USER to the imagemedium

apps/api/Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/deploy-api.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.