FreeAPI.app (hiteshchoudhary/apihub): a self-hosted API playground for portfolio projects

What problem FreeAPI.app solves, and who it is actually for

Practising API consumption is awkward. Public APIs exist, but they change, rate-limit you, require keys, or disappear mid-tutorial. FreeAPI.app takes the opposite approach: it is a single API hub you host yourself, so the endpoints stay put while you build. The README frames the goal as "a single source API hub that can be used to learn api handling in any programming language" and names frontend, mobile and backend developers as the audience. The repository topics repeat that: api, backend, frontend, mobile-development.

The second use case is portfolio work. The README distinguishes beginner endpoints, which give hands-on practice with response handling, from advanced APIs meant to stretch integration skills. That split matters, because a frontend developer building a first React or Flutter app needs predictable JSON and a login flow more than they need scale. The examples directory reinforces the intent: examples/apps, examples/kitchen-sink and examples/public suggest sample front ends shipped alongside the server rather than a pure library.

Inside the Express and MongoDB stack

The server is an Express 4.21.1 application written as an ES module ("type": "module" in package.json), started through nodemon with dotenv preloaded. Persistence is MongoDB through Mongoose 7.8.4, with mongoose-aggregate-paginate-v2 for paginated aggregate queries. That last dependency tells you the API surface is designed around list endpoints with paging, which is exactly the pattern a learner needs to practise.

Authentication is assembled from separate pieces rather than one framework: jsonwebtoken for access and refresh tokens, express-session for sessions, bcrypt for password hashing, and Passport with passport-github2 and passport-google-oauth20 for OAuth logins. Mail goes through nodemailer with mailgen for templating, and payments through the razorpay SDK. Uploads use multer, real-time features use socket.io, and the API reference is served by swagger-ui-express reading a YAML file (the yaml package is a dependency).

Two operational details are visible in the configuration. The .env.sample sets ACCESS_TOKEN_EXPIRY=1d and REFRESH_TOKEN_EXPIRY=10d, using the ms format, so token lifetimes are configurable rather than hardcoded. And CORS_ORIGIN defaults to http://localhost:3000 with a comment that it must be either "*" or a comma separated list of origins. If your front end runs on a different port, requests will fail until you change that value. The stack also includes express-rate-limit, express-compression, morgan and winston, so logging, compression and rate limiting are wired in from the start.

Installing FreeAPI.app with Docker and making a first request

The README marks Docker as the recommended path. You need Docker installed, the repository cloned, and an .env file created at the root by copying .env.sample and filling in the credentials you need. The compose file defines two services: backend, built from the Dockerfile and exposed on 8080, and mongodb on 27017, with a named volume for the database. The backend waits on mongodb via depends_on and reads .env through env_file.

Start the stack with the command the README gives:

docker-compose up --build --attach backend

The --build flag rebuilds the image and --attach limits the log output to the Node container instead of mixing in the MongoDB logs. The Dockerfile is based on node:20.13.1-alpine, installs dependencies with yarn install --pure-lockfile, runs prepare.js, and exposes port 8080. Once the log settles, the API is reachable at the host and port you set in .env.sample, which defaults to 8080.

The README also documents a local path without Docker, which starts by installing Yarn. The package scripts are the reference for what runs: npm start launches nodemon with dotenv and experimental JSON modules against src/index.js, and npm run start:test-server boots the e2e test server.

yarn install
npm start

For the environment, the minimum you need to change is the database URI and the host URL:

PORT=8080
MONGODB_URI=mongodb://mongodb:27017
FREEAPI_HOST_URL=http://localhost:8080

If you run MongoDB on your own machine rather than in the compose network, the .env.sample comment says to use mongodb://localhost:27017 instead. The mail and payment blocks in .env.sample are placeholders (__mailtrap_smtp_host__, and so on) and are only needed if you exercise those endpoints.

The two-hour reset is a design constraint, not a bug report

The README carries an explicit warning: the hosted instance resets the entire server, including the file system and the MongoDB database, every two hours to control hosting costs. Uploaded images and user data written during that window are deleted and unrecoverable, and the reboot can interrupt requests for one to two minutes. The stated remedies are running locally by cloning the project, or self-hosting through a pre-built Railway template linked from the README.

This is the sharpest limitation in the project, and it should shape how you use it. Any tutorial that depends on persistent state, such as uploading a profile picture and reading it back tomorrow, will break against the hosted URL. The same applies to anything you build for a demo day or a portfolio link you expect to stay live. Treat the hosted instance as a scratchpad and your local copy as the real environment.

There is a second boundary worth naming: FreeAPI.app is a learning hub, not a production backend. The README never claims an uptime target, and the reset policy makes one impossible on the hosted side. If you need an API that other people depend on, the project is the wrong tool; use it to learn the shape of HTTP, auth and pagination, then move those skills to infrastructure you control.

How FreeAPI.app differs from a mock server or a public API directory

The nearest alternatives are mock servers such as JSON Server or Mockoon, and directories of public APIs. The difference is in what you get out of the box. A mock server gives you whatever JSON you write, with no auth, no file uploads and no database, so you never practise a refresh-token flow or a paginated aggregate query. FreeAPI.app ships those flows as working code: JWT access and refresh tokens with configurable expiry, Passport-based GitHub and Google login, multer uploads, socket.io, and Swagger UI documentation served from the running app.

A public API directory sits at the other extreme. You get real third-party services, but you also inherit their keys, quotas and occasional outages, and you cannot read their source when a response surprises you. FreeAPI.app is open source and runs on your machine, so you can open src/index.js and trace why a handler returned what it did. That traceability is the actual differentiator, more than the endpoint list.

The trade-off is setup weight. JSON Server is one command and no database. FreeAPI.app needs MongoDB, a populated .env, and enough credentials to satisfy whichever optional integrations you touch. If your goal is a throwaway stub for a single screen, that weight is not worth it.

Maintenance, licensing and what to check before depending on it

The repository is not archived, and the last push was on 2026-05-05. The most recent tagged release listed is v1.3.0 from 2024-03-03, while package.json reports version 1.3.1, so the published tags trail the working tree. There is a commitlint configuration, a Husky hooks directory, lint-staged and Prettier config in the repository root, which indicates the project enforces commit and formatting conventions on contributions. The README points contributors at CONTRIBUTING.md, CONTRIBUTING_CODE_COVERAGE.md and CONTRIBUTING_FRONTEND.md.

On licensing, the two signals disagree and you should resolve that yourself rather than assume. The package.json declares "license": "ISC", while the repository metadata is flagged NOASSERTION, which usually means an automated licence detector could not match the LICENSE.md file to a known template. Read LICENSE.md before you redistribute anything or ship it inside a commercial product. This is a factual observation about the repository, not legal advice.

The upgrade cost is mostly environmental. The Dockerfile pins node:20.13.1-alpine, so moving to a newer Node line means editing that base image and re-running yarn install against the lockfile. Because the app reads configuration from .env, upgrading means re-checking .env.sample for keys that were added since your copy, particularly in the mail and payment blocks. The e2e suite runs through Playwright, so npm run test:playwright and the e2e/test-server.js entry point are the places to look when you want to confirm an upgrade did not break behaviour.

Editorial conclusion

Adopt FreeAPI.app if you need a local API surface to practise fetch calls, auth flows and pagination, and you are willing to run MongoDB alongside it. Do not adopt it as production infrastructure: the hosted instance resets every two hours, and the repository is a learning hub rather than a service with an uptime commitment. Before you commit, read .env.sample end to end, confirm which optional integrations (Mailtrap, Razorpay, OAuth) you actually need, and check the LICENSE.md file, because the repository is flagged NOASSERTION while package.json declares ISC.

Frequently asked questions

Official sources

1. hiteshchoudhary/apihub on GitHub
2. Issues
3. Project website
4. README
5. Releases