Vibecode FileChanger
track this build5 steps, step by step0%YES · one-shottable
The conversion is other people's software. Pandoc, ImageMagick and FFmpeg do the actual work, the format list looks enormous because those three projects are enormous, and a coding agent can wire all of them behind an upload form and a REST endpoint in one sitting. What a subscription buys is not the conversion, it is somebody else running a box that eats untrusted files from strangers all day without falling over, and keeping a few hundred format pairs working after every upstream release. Point it at your own files on your own machine and most of that risk simply is not yours, which is why this one is a yes.
the project pack4 files · fastest path to a working personal build
You are building a lean indie version of FileChanger.
Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt.
===== README.md =====
# FileChanger indie build
## Goal
Build the smallest trustworthy replacement for the core FileChanger workflow for one developer or a tiny team.
## Scope
Accept a file, shell out to pandoc, ImageMagick or FFmpeg depending on what it is, and hand the converted bytes back over HTTP or MCP.
## Quick start
1. Install the documented dependencies.
2. Copy `.env.example` to `.env`.
3. Run the development command chosen during implementation.
4. Complete the acceptance checks in `BUILD_PLAN.md`.
## Honest limits
This build deliberately does not replace:
- sandboxing, because your version runs files straight through the same toolchain as everything else on the machine
- the long tail of format pairs, where the fix is usually a missing font, a filter flag or an upstream bug
- queueing and timeouts for large video, which is where the compute bill actually lives
- a hosted MCP server and API keys your other tools can reach from anywhere, not just from localhost
- somebody else being on call when a LibreOffice or LaTeX upgrade quietly breaks PDF output
If those capabilities are essential, use Pandoc instead of pretending the gap is solved.
===== AGENTS.md =====
# Agent instructions
- Optimize for a working, understandable weekend build.
- Prefer the fewest moving parts that satisfy the brief.
- Do not invent cryptography, security guarantees, APIs, or compliance claims.
- Keep secrets out of source control and logs.
- Add focused tests for destructive, security-sensitive, and data-loss paths.
- Run the project checks before declaring the build complete.
- Record any deliberate shortcut in the README under "Tradeoffs".
===== BUILD_PLAN.md =====
# Build plan
## Original build brief
Build me a personal file conversion service in an empty repo. Requirements:
- Python 3.12, FastAPI, uv for dependencies, SQLite for job state. One process,
no broker, no microservices, no alternative stacks.
- Never write a converter. Shell out to pandoc for markup and documents,
LibreOffice headless for Office, ImageMagick for images, FFmpeg for media.
- POST /convert takes a file, a source and a target format and returns the bytes
below a size threshold set in config. Above it the same route returns a job
id, GET /jobs/{id} reports its state and GET /jobs/{id}/result streams the
file. One background worker thread is enough, do not add Celery.
- Build the format matrix at startup from `pandoc --list-input-formats`,
`--list-output-formats`, `ffmpeg -formats` and `magick -list format` rather
than hardcoding it, and serve it at GET /formats.
- Treat every upload as hostile: convert in a temp dir with a wall-clock
timeout, an output size cap and no network, then delete the inputs whether it
worked or not. Log the failing command and its stderr, never return either.
- Ship an MCP server over stdio using the official Python SDK, exposing convert
and formats as tools so agents can convert without going through HTTP.
- Authenticate with API keys stored hashed in SQLite. Show the plaintext once at
creation and support revocation.
- One HTML page, no JS framework: pick a file, pick a target from /formats,
download the result.
- One Dockerfile installing pandoc, typst, libreoffice-core, imagemagick and
ffmpeg, a compose file with a volume for the database, config in .env and a
committed .env.example.
- Out of scope: accounts, billing, metering, quotas, telemetry, multi-tenancy
and any hosted control plane.
- Test one round trip per engine (Markdown to PDF, PNG to WebP, WAV to MP3), an
oversized upload and a conversion that hits the timeout. README covers setup,
formats, security assumptions and where data lives. Finish by running the
tests and listing the commands used.
## Required capabilities
- pandoc
- FFmpeg
- ImageMagick
- LibreOffice headless for Office formats
- Typst or a LaTeX install if you want PDF out
## Delivery order
1. Scaffold the smallest runnable application and document its commands.
2. Implement the primary data model and core workflow.
3. Add validation, safe failure states, and persistence.
4. Cover the critical path with automated tests.
5. Exercise a clean install from the README and fix every missing step.
## Done when
- A new user can go from clone to first successful workflow using only the README.
- The core workflow works without paid infrastructure unless the brief requires it.
- Tests cover the highest-risk behavior.
- Known limitations are explicit rather than hidden.
===== .env.example =====
# Copy to .env and document every variable when it is introduced.
# Never put real credentials in this file.
APP_ENV=development
# Add only values required by the selected implementation.You are building a lean indie version of FileChanger.
Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt.
===== README.md =====
# FileChanger indie build
## Goal
Build the smallest trustworthy replacement for the core FileChanger workflow for one developer or a tiny team.
## Scope
Accept a file, shell out to pandoc, ImageMagick or FFmpeg depending on what it is, and hand the converted bytes back over HTTP or MCP.
## Quick start
1. Install the documented dependencies.
2. Copy `.env.example` to `.env`.
3. Run the development command chosen during implementation.
4. Complete the acceptance checks in `BUILD_PLAN.md`.
## Honest limits
This build deliberately does not replace:
- sandboxing, because your version runs files straight through the same toolchain as everything else on the machine
- the long tail of format pairs, where the fix is usually a missing font, a filter flag or an upstream bug
- queueing and timeouts for large video, which is where the compute bill actually lives
- a hosted MCP server and API keys your other tools can reach from anywhere, not just from localhost
- somebody else being on call when a LibreOffice or LaTeX upgrade quietly breaks PDF output
If those capabilities are essential, use Pandoc instead of pretending the gap is solved.
===== AGENTS.md =====
# Agent instructions
- Optimize for a working, understandable weekend build.
- Prefer the fewest moving parts that satisfy the brief.
- Do not invent cryptography, security guarantees, APIs, or compliance claims.
- Keep secrets out of source control and logs.
- Add focused tests for destructive, security-sensitive, and data-loss paths.
- Run the project checks before declaring the build complete.
- Record any deliberate shortcut in the README under "Tradeoffs".
===== BUILD_PLAN.md =====
# Build plan
## Original build brief
Build me a personal file conversion service in an empty repo. Requirements:
- Python 3.12, FastAPI, uv for dependencies, SQLite for job state. One process,
no broker, no microservices, no alternative stacks.
- Never write a converter. Shell out to pandoc for markup and documents,
LibreOffice headless for Office, ImageMagick for images, FFmpeg for media.
- POST /convert takes a file, a source and a target format and returns the bytes
below a size threshold set in config. Above it the same route returns a job
id, GET /jobs/{id} reports its state and GET /jobs/{id}/result streams the
file. One background worker thread is enough, do not add Celery.
- Build the format matrix at startup from `pandoc --list-input-formats`,
`--list-output-formats`, `ffmpeg -formats` and `magick -list format` rather
than hardcoding it, and serve it at GET /formats.
- Treat every upload as hostile: convert in a temp dir with a wall-clock
timeout, an output size cap and no network, then delete the inputs whether it
worked or not. Log the failing command and its stderr, never return either.
- Ship an MCP server over stdio using the official Python SDK, exposing convert
and formats as tools so agents can convert without going through HTTP.
- Authenticate with API keys stored hashed in SQLite. Show the plaintext once at
creation and support revocation.
- One HTML page, no JS framework: pick a file, pick a target from /formats,
download the result.
- One Dockerfile installing pandoc, typst, libreoffice-core, imagemagick and
ffmpeg, a compose file with a volume for the database, config in .env and a
committed .env.example.
- Out of scope: accounts, billing, metering, quotas, telemetry, multi-tenancy
and any hosted control plane.
- Test one round trip per engine (Markdown to PDF, PNG to WebP, WAV to MP3), an
oversized upload and a conversion that hits the timeout. README covers setup,
formats, security assumptions and where data lives. Finish by running the
tests and listing the commands used.
## Required capabilities
- pandoc
- FFmpeg
- ImageMagick
- LibreOffice headless for Office formats
- Typst or a LaTeX install if you want PDF out
## Delivery order
1. Scaffold the smallest runnable application and document its commands.
2. Implement the primary data model and core workflow.
3. Add validation, safe failure states, and persistence.
4. Cover the critical path with automated tests.
5. Exercise a clean install from the README and fix every missing step.
## Done when
- A new user can go from clone to first successful workflow using only the README.
- The core workflow works without paid infrastructure unless the brief requires it.
- Tests cover the highest-risk behavior.
- Known limitations are explicit rather than hidden.
===== .env.example =====
# Copy to .env and document every variable when it is introduced.
# Never put real credentials in this file.
APP_ENV=development
# Add only values required by the selected implementation.You are building a production product version of FileChanger.
Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt.
===== PRODUCT.md =====
# FileChanger product brief
## Problem
The conversion is other people's software. Pandoc, ImageMagick and FFmpeg do the actual work, the format list looks enormous because those three projects are enormous, and a coding agent can wire all of them behind an upload form and a REST endpoint in one sitting. What a subscription buys is not the conversion, it is somebody else running a box that eats untrusted files from strangers all day without falling over, and keeping a few hundred format pairs working after every upstream release. Point it at your own files on your own machine and most of that risk simply is not yours, which is why this one is a yes.
## Product outcome
Accept a file, shell out to pandoc, ImageMagick or FFmpeg depending on what it is, and hand the converted bytes back over HTTP or MCP.
## Target user
A serious builder who needs a maintainable product foundation rather than a one-off demo.
## Required capabilities
- pandoc
- FFmpeg
- ImageMagick
- LibreOffice headless for Office formats
- Typst or a LaTeX install if you want PDF out
## Explicit non-goals for v1
- sandboxing, because your version runs files straight through the same toolchain as everything else on the machine
- the long tail of format pairs, where the fix is usually a missing font, a filter flag or an upstream bug
- queueing and timeouts for large video, which is where the compute bill actually lives
- a hosted MCP server and API keys your other tools can reach from anywhere, not just from localhost
- somebody else being on call when a LibreOffice or LaTeX upgrade quietly breaks PDF output
## Success criteria
- The primary workflow is measurable end to end.
- Setup is reproducible in a clean environment.
- Failure, recovery, and support paths are documented.
- Product claims match what the implementation actually guarantees.
===== ARCHITECTURE.md =====
# Architecture
## Starting brief
Build me a personal file conversion service in an empty repo. Requirements:
- Python 3.12, FastAPI, uv for dependencies, SQLite for job state. One process,
no broker, no microservices, no alternative stacks.
- Never write a converter. Shell out to pandoc for markup and documents,
LibreOffice headless for Office, ImageMagick for images, FFmpeg for media.
- POST /convert takes a file, a source and a target format and returns the bytes
below a size threshold set in config. Above it the same route returns a job
id, GET /jobs/{id} reports its state and GET /jobs/{id}/result streams the
file. One background worker thread is enough, do not add Celery.
- Build the format matrix at startup from `pandoc --list-input-formats`,
`--list-output-formats`, `ffmpeg -formats` and `magick -list format` rather
than hardcoding it, and serve it at GET /formats.
- Treat every upload as hostile: convert in a temp dir with a wall-clock
timeout, an output size cap and no network, then delete the inputs whether it
worked or not. Log the failing command and its stderr, never return either.
- Ship an MCP server over stdio using the official Python SDK, exposing convert
and formats as tools so agents can convert without going through HTTP.
- Authenticate with API keys stored hashed in SQLite. Show the plaintext once at
creation and support revocation.
- One HTML page, no JS framework: pick a file, pick a target from /formats,
download the result.
- One Dockerfile installing pandoc, typst, libreoffice-core, imagemagick and
ffmpeg, a compose file with a volume for the database, config in .env and a
committed .env.example.
- Out of scope: accounts, billing, metering, quotas, telemetry, multi-tenancy
and any hosted control plane.
- Test one round trip per engine (Markdown to PDF, PNG to WebP, WAV to MP3), an
oversized upload and a conversion that hits the timeout. README covers setup,
formats, security assumptions and where data lives. Finish by running the
tests and listing the commands used.
## Boundaries
Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors.
## Production baseline
- Configuration: validated at startup with safe local defaults where possible.
- Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives.
- Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions.
- Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts.
- Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists.
- Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test.
## Decision records
For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
===== AGENTS.md =====
# Agent instructions
- Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code.
- Implement milestone by milestone; keep each change reviewable and leave the application runnable.
- Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present.
- Never invent cryptography or silently weaken a requirement to make a test pass.
- Use provider interfaces for external services and deterministic fakes in tests.
- Add migrations and rollback or recovery notes for persistent data changes.
- Log useful operational context without credentials, tokens, passwords, or personal data.
- Update documentation and run all checks before completing a milestone.
===== MILESTONES.md =====
# Delivery milestones
## M0 — Decisions and scaffold
- Confirm the runtime, persistence model, threat boundaries, and deployment target.
- Create a reproducible local environment and continuous checks.
## M1 — Core workflow
- Implement the smallest end-to-end product path with validation and tests.
- Keep integrations behind interfaces.
## M2 — Trust layer
- Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards.
- Test abuse cases and destructive operations.
## M3 — Operability
- Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration.
## M4 — Release gate
- Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise.
- Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
===== OPERATIONS.md =====
# Operations
## Before release
- Validate configuration and secrets at startup.
- Define backup, restore, and rollback procedures and test them.
- Document logs, error tracking, health signals, and alert ownership.
- Set dependency update and vulnerability review expectations.
## Incident checklist
1. Contain the issue without destroying evidence or user data.
2. Record the timeline and affected scope.
3. Rotate exposed secrets and revoke compromised sessions or credentials.
4. Restore from a verified source when needed.
5. Document the root cause, remediation, and regression test.
## Launch constraint
Do not market omitted FileChanger capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.README.md
# FileChanger indie build ## Goal Build the smallest trustworthy replacement for the core FileChanger workflow for one developer or a tiny team. ## Scope Accept a file, shell out to pandoc, ImageMagick or FFmpeg depending on what it is, and hand the converted bytes back over HTTP or MCP. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - sandboxing, because your version runs files straight through the same toolchain as everything else on the machine - the long tail of format pairs, where the fix is usually a missing font, a filter flag or an upstream bug - queueing and timeouts for large video, which is where the compute bill actually lives - a hosted MCP server and API keys your other tools can reach from anywhere, not just from localhost - somebody else being on call when a LibreOffice or LaTeX upgrade quietly breaks PDF output If those capabilities are essential, use Pandoc instead of pretending the gap is solved.
AGENTS.md
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan
## Original build brief
Build me a personal file conversion service in an empty repo. Requirements:
- Python 3.12, FastAPI, uv for dependencies, SQLite for job state. One process,
no broker, no microservices, no alternative stacks.
- Never write a converter. Shell out to pandoc for markup and documents,
LibreOffice headless for Office, ImageMagick for images, FFmpeg for media.
- POST /convert takes a file, a source and a target format and returns the bytes
below a size threshold set in config. Above it the same route returns a job
id, GET /jobs/{id} reports its state and GET /jobs/{id}/result streams the
file. One background worker thread is enough, do not add Celery.
- Build the format matrix at startup from `pandoc --list-input-formats`,
`--list-output-formats`, `ffmpeg -formats` and `magick -list format` rather
than hardcoding it, and serve it at GET /formats.
- Treat every upload as hostile: convert in a temp dir with a wall-clock
timeout, an output size cap and no network, then delete the inputs whether it
worked or not. Log the failing command and its stderr, never return either.
- Ship an MCP server over stdio using the official Python SDK, exposing convert
and formats as tools so agents can convert without going through HTTP.
- Authenticate with API keys stored hashed in SQLite. Show the plaintext once at
creation and support revocation.
- One HTML page, no JS framework: pick a file, pick a target from /formats,
download the result.
- One Dockerfile installing pandoc, typst, libreoffice-core, imagemagick and
ffmpeg, a compose file with a volume for the database, config in .env and a
committed .env.example.
- Out of scope: accounts, billing, metering, quotas, telemetry, multi-tenancy
and any hosted control plane.
- Test one round trip per engine (Markdown to PDF, PNG to WebP, WAV to MP3), an
oversized upload and a conversion that hits the timeout. README covers setup,
formats, security assumptions and where data lives. Finish by running the
tests and listing the commands used.
## Required capabilities
- pandoc
- FFmpeg
- ImageMagick
- LibreOffice headless for Office formats
- Typst or a LaTeX install if you want PDF out
## Delivery order
1. Scaffold the smallest runnable application and document its commands.
2. Implement the primary data model and core workflow.
3. Add validation, safe failure states, and persistence.
4. Cover the critical path with automated tests.
5. Exercise a clean install from the README and fix every missing step.
## Done when
- A new user can go from clone to first successful workflow using only the README.
- The core workflow works without paid infrastructure unless the brief requires it.
- Tests cover the highest-risk behavior.
- Known limitations are explicit rather than hidden..env.example
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
PRODUCT.md
# FileChanger product brief ## Problem The conversion is other people's software. Pandoc, ImageMagick and FFmpeg do the actual work, the format list looks enormous because those three projects are enormous, and a coding agent can wire all of them behind an upload form and a REST endpoint in one sitting. What a subscription buys is not the conversion, it is somebody else running a box that eats untrusted files from strangers all day without falling over, and keeping a few hundred format pairs working after every upstream release. Point it at your own files on your own machine and most of that risk simply is not yours, which is why this one is a yes. ## Product outcome Accept a file, shell out to pandoc, ImageMagick or FFmpeg depending on what it is, and hand the converted bytes back over HTTP or MCP. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - pandoc - FFmpeg - ImageMagick - LibreOffice headless for Office formats - Typst or a LaTeX install if you want PDF out ## Explicit non-goals for v1 - sandboxing, because your version runs files straight through the same toolchain as everything else on the machine - the long tail of format pairs, where the fix is usually a missing font, a filter flag or an upstream bug - queueing and timeouts for large video, which is where the compute bill actually lives - a hosted MCP server and API keys your other tools can reach from anywhere, not just from localhost - somebody else being on call when a LibreOffice or LaTeX upgrade quietly breaks PDF output ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
ARCHITECTURE.md
# Architecture
## Starting brief
Build me a personal file conversion service in an empty repo. Requirements:
- Python 3.12, FastAPI, uv for dependencies, SQLite for job state. One process,
no broker, no microservices, no alternative stacks.
- Never write a converter. Shell out to pandoc for markup and documents,
LibreOffice headless for Office, ImageMagick for images, FFmpeg for media.
- POST /convert takes a file, a source and a target format and returns the bytes
below a size threshold set in config. Above it the same route returns a job
id, GET /jobs/{id} reports its state and GET /jobs/{id}/result streams the
file. One background worker thread is enough, do not add Celery.
- Build the format matrix at startup from `pandoc --list-input-formats`,
`--list-output-formats`, `ffmpeg -formats` and `magick -list format` rather
than hardcoding it, and serve it at GET /formats.
- Treat every upload as hostile: convert in a temp dir with a wall-clock
timeout, an output size cap and no network, then delete the inputs whether it
worked or not. Log the failing command and its stderr, never return either.
- Ship an MCP server over stdio using the official Python SDK, exposing convert
and formats as tools so agents can convert without going through HTTP.
- Authenticate with API keys stored hashed in SQLite. Show the plaintext once at
creation and support revocation.
- One HTML page, no JS framework: pick a file, pick a target from /formats,
download the result.
- One Dockerfile installing pandoc, typst, libreoffice-core, imagemagick and
ffmpeg, a compose file with a volume for the database, config in .env and a
committed .env.example.
- Out of scope: accounts, billing, metering, quotas, telemetry, multi-tenancy
and any hosted control plane.
- Test one round trip per engine (Markdown to PDF, PNG to WebP, WAV to MP3), an
oversized upload and a conversion that hits the timeout. README covers setup,
formats, security assumptions and where data lives. Finish by running the
tests and listing the commands used.
## Boundaries
Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors.
## Production baseline
- Configuration: validated at startup with safe local defaults where possible.
- Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives.
- Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions.
- Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts.
- Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists.
- Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test.
## Decision records
For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.AGENTS.md
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
MILESTONES.md
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
OPERATIONS.md
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted FileChanger capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent
Nobody pays for the conversions that work. They pay for the awkward ones: the DOCX with tracked changes, the HEIC nobody can open, the MXF from a camera, the 4 GB video that has to finish while a browser tab is still open. Doing those reliably means keeping a toolchain installed, patched and fenced off from the files it is fed, and doing it for other people means doing it while strangers upload whatever they like. That upkeep is the product. The convert button is a weekend.
xsandboxing, because your version runs files straight through the same toolchain as everything else on the machine
xthe long tail of format pairs, where the fix is usually a missing font, a filter flag or an upstream bug
xqueueing and timeouts for large video, which is where the compute bill actually lives
xa hosted MCP server and API keys your other tools can reach from anywhere, not just from localhost
xsomebody else being on call when a LibreOffice or LaTeX upgrade quietly breaks PDF output
share on X ↗"I just replaced FileChanger ($39/mo) with one prompt"
Don't feel like building it? These folks already made it free.
PandocIf the job is only documents, the paid service is a web form on top of this. Installer, twenty years of releases, and no upload step.open source↗
ConvertXA self-hosted web converter that wraps the same engines, with accounts and a job list already built. One container and you own the whole pipeline.open source↗
VERTConverts images and documents in the browser tab itself, so the file never leaves the machine. Video is the exception and needs their server or yours.open source↗all 3 free alternatives to FileChanger →· no votes, no pay-to-list · just what's real
FileChanger pricing
| plan | monthly | annual (per mo) | what you get |
|---|---|---|---|
| free | $0 | $0 | 200 MB documents + 200 MB images + 200 MB audio + 50 MB video per calendar month; about 200 document conversions; API keys and MCP access |
| starter | $39 | — | Per month: 100 GB documents, 100 GB images, 50 GB audio, 10 GB video; about 100,000 document conversions; API + MCP |
| pro | $99 | — | Per month: 350 GB documents, 350 GB images, 200 GB audio, 50 GB video; about 350,000 document conversions; API + MCP |
free tier200 MB documents, 200 MB images, 200 MB audio and 50 MB video per calendar month; about 200 document conversions; API and MCP included
billingmonthly only; change or cancel any time through Polar
hidden costsAllowances are separate by format group and meter input bytes, not output size; no annual plan is published
verified 2026-08-13 · source ↗
Is FileChanger free?
The free tier is real and permanent: 200 MB each of documents, images and audio per month, 50 MB of video, and API keys plus MCP access included. Paid is Starter at $39/mo (checked 2026-08-07).
Vibecode FileChanger
Yes. A competent AI coding agent (Claude Code, Codex, Cursor) can build a usable personal FileChanger replacement in one session with the prompt on this page. It runs on your own machine or server with no subscription.
How much does FileChanger cost?
FileChanger costs about $39/month (Starter, checked 2026-08-07), which is $468 per year. That's what you save by replacing it with one prompt.
What do I lose by replacing FileChanger?
Honestly: sandboxing, because your version runs files straight through the same toolchain as everything else on the machine; the long tail of format pairs, where the fix is usually a missing font, a filter flag or an upstream bug; queueing and timeouts for large video, which is where the compute bill actually lives; a hosted MCP server and API keys your other tools can reach from anywhere, not just from localhost; somebody else being on call when a LibreOffice or LaTeX upgrade quietly breaks PDF output. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to FileChanger?
Yes: Pandoc (If the job is only documents, the paid service is a web form on top of this. Installer, twenty years of releases, and no upload step.) ConvertX (A self-hosted web converter that wraps the same engines, with accounts and a job list already built. One container and you own the whole pipeline.) VERT (Converts images and documents in the browser tab itself, so the file never leaves the machine. Video is the exception and needs their server or yours.) All 3 curated free alternatives are at vibecodeit.com/filechanger/alternatives. The prompt is for when you want it exactly your way.