Apply for AI Grants India

GitHub can be your portfolio, documentation hub, and deployment control centre—but only if a visitor can understand your project quickly and verify that it works. A repository filled with source files and no context is not a portfolio; it is an archive.

For Indian students, developers, and founders, a strong GitHub project can support internship applications, freelance work, open-source credibility, and early customer conversations. This guide explains how to host portfolio projects on GitHub in a way that is technically sound, easy to evaluate, and practical to maintain in 2026.

Decide what GitHub should host

GitHub hosts source code, documentation, static websites, release files, and automation. It is not a general-purpose server for continuously running APIs, databases, private model weights, or GPU workloads.

Choose the hosting model before creating the repository:

• Static site: Use GitHub Pages for HTML, CSS, JavaScript, documentation, and many frontend builds.
• Frontend application: Keep the code on GitHub and deploy it through GitHub Actions to GitHub Pages or a service such as Vercel or Netlify.
• Backend or API: Store the code on GitHub, then deploy it to a suitable cloud platform with environment variables and a managed database.
• Machine learning project: Keep code, configuration, small samples, evaluation results, and reproducible instructions on GitHub. Store large datasets and model artefacts elsewhere.

If you are still choosing a project, study examples in machine learning portfolio projects for beginners in India and select one with a clear user problem, measurable output, and a demo you can maintain.

Prepare a clean, safe repository

Create a repository name that is specific and readable, such as ಕನ್ನಡ-ocr-api only if your tooling reliably supports it; otherwise use a simple form such as indic-language-ocr-api. Add a concise description and select relevant repository topics.

Before your first push:

• Add a suitable .gitignore for Python, Node.js, or your chosen stack.
• Never commit API keys, passwords, private certificates, .env files, or user data.
• Provide .env.example with variable names but no real values.
• Separate application code, tests, documentation, scripts, and infrastructure.
• Pin important dependencies and record the supported runtime version.
• Remove generated folders, local databases, notebook outputs, and debugging files unless they demonstrate a result.
• Add a licence that matches your intended use. MIT is permissive; Apache 2.0 also addresses patent rights. Do not add a licence casually if the project includes third-party code with incompatible terms.

Enable secret scanning and push protection where your GitHub plan supports them. If a credential is exposed, deleting the file is not enough: revoke and rotate the credential immediately, then inspect the repository history.

Write a README that answers evaluation questions

Your README.md is the project’s landing page. A reviewer should understand the problem, see evidence of the result, and start the project without guessing.

Use this structure:

1. One-line value proposition: State who the project helps and what it does.
2. Demo first: Add a live link, short screen recording, screenshots, or sample API responses near the top.
3. Problem and scope: Explain what you built, what you deliberately did not build, and why.
4. Architecture: Include a small diagram or describe the frontend, backend, data store, model, and deployment path.
5. Features: List the capabilities that matter to a user, not every library imported.
6. Results: Report latency, accuracy, test coverage, cost assumptions, or other relevant measurements.
7. Local setup: Give exact commands from clone to successful run.
8. Configuration: Document environment variables, migrations, seed data, and required services.
9. Limitations and risks: Mention unsupported languages, known failure cases, data constraints, and safety considerations.
10. Licence and contribution guidance: Make reuse and contributions clear.

For AI projects, include the dataset source, licence, preprocessing steps, evaluation method, model version, and examples of incorrect outputs. A project based on Indian languages, local commerce, agriculture, education, or public services becomes more credible when it explains the India-specific assumptions rather than presenting a generic demo.

A focused repository is usually stronger than ten unfinished ones. Use related work to show depth: best open source AI projects for student developers offers useful directions for projects that can demonstrate both engineering and community value.

Publish a static site with GitHub Pages

GitHub Pages is suitable for static files and frontend builds. In the repository, open Settings → Pages, choose GitHub Actions as the source, and select an appropriate deployment workflow. For a plain HTML site, publishing from the main branch and the /docs folder can also work.

Check these details before sharing the URL:

• Use relative asset paths so images and styles load under a project subpath.
• Configure the correct base path for React, Vite, Astro, or similar frameworks.
• Add a custom domain only after the default Pages URL works.
• Configure HTTPS and verify that redirects and canonical URLs behave correctly.
• Test the site on mobile networks and low-end devices.
• Add meaningful page titles, descriptions, alt text, and a visible project identity.

For a portfolio with several projects, create a landing page that links to each repository and demo. You can also document your approach in building personalized portfolio websites using AI agents, but review every generated page for accuracy, accessibility, and unnecessary claims.

Deploy applications without confusing GitHub with hosting

A full-stack application normally has separate deployment targets. GitHub stores the code and runs automation; another platform runs the service. Connect the repository to your chosen provider, configure build and start commands, and store secrets in the provider’s secret manager rather than in GitHub files.

For an AI application, distinguish the interface from the inference layer. A small demo may call a hosted model API, while a larger model may require a GPU service. Keep prompts, model identifiers, rate limits, fallback behaviour, and estimated per-request cost documented. If your project is an agent, explain tool permissions and failure handling; how to deploy open source AI agents covers the operational concerns that a simple README often misses.

Do not upload large datasets or model weights directly to a normal Git repository. GitHub has file and repository limits, and large binaries make cloning slow. Use Git LFS where appropriate, or publish artefacts through a model or data registry and provide checksums and download instructions.

Add GitHub Actions for proof of engineering quality

A modest CI workflow can make a portfolio project substantially easier to trust. Start with checks that run on pull requests and pushes:

• Install the supported runtime and dependencies.
• Run formatting and lint checks.
• Execute unit and integration tests.
• Build the frontend or package the application.
• Scan dependencies and reject accidental secrets where possible.

Keep workflows fast and deterministic. Cache dependencies carefully, use a lockfile, and avoid embedding production secrets in pull-request jobs. Display a workflow badge only when the workflow reflects meaningful checks; a green badge for an empty test suite adds little value.

Use releases or tagged versions when others may depend on the project. Record breaking changes, migration steps, and known issues in release notes rather than forcing visitors to inspect commit history.

Make the project discoverable and easy to assess

Add a useful repository description, three to six accurate topics, a licence, and a social preview image. Pin your strongest repositories on your GitHub profile and keep their default branches healthy. Archive experiments that are no longer maintained instead of leaving visitors to infer their status.

Your project should answer five questions within a minute:

• What problem does it solve?
• Who is it for?
• Can I see it working?
• Can I run or inspect it?
• What did the builder actually learn or measure?

If you are building a computer vision project, document data splits, inference examples, and failure cases; the guide to building computer vision models on GitHub is a useful companion. For community credibility, contributing to established repositories can complement your own work—see how to contribute to AI GitHub repositories in India.

Final pre-publication checklist

Before sharing the repository on a CV, LinkedIn, application, or grant form, verify that:

• The demo URL works without your local machine running.
• Setup instructions work in a fresh environment.
• No secrets or personal data are committed.
• Tests and build status are current.
• Screenshots match the current interface.
• Licence, attribution, and data terms are present.
• Limitations, costs, and model details are honest.
• An unfamiliar engineer can identify the next useful action.

A polished GitHub portfolio is not about decorative badges or maximum code volume. It is a maintained, reproducible record of how you identify a problem, build a solution, measure it, and communicate its boundaries.