Self-hosting on your own server

For an institute IT team taking on IdeaScore as a self-hosted application: what you are deploying, what the machine needs, the two supported deployment shapes, the database, a base path such as /innovation, TLS, backups and upgrades.

It gives no commands or version numbers; those come with the deployment package for your release. What follows is what the environment must provide, so you can size and approve it first.

Before you start

• A decision on hosting. The cloud deployment at app.ideascore.online needs none of this. Institutions self-host when data residency, procurement or network policy calls for it.
• A named owner for the VM and a deputy with access. A single point of failure on an application that runs a funding call is a governance problem.
• The base path, if the application will sit under an existing institutional domain — for example /innovation.
• A TLS certificate, or access to whatever issues them on your network.
• Outbound HTTPS for transactional email and, where IdeaScore AI is licensed, for its research requests. If your egress is filtered, get the destinations allow-listed before the install window.
• A backup destination that is not the same machine.

What you are deploying

Three parts, plus a reverse proxy in front.

Uploaded files — pitch decks and attachments — sit on a filesystem path the API service owns. Treat that directory as data: it must be on a volume you back up and it must survive an upgrade.

Requirements

One Linux virtual machine is enough for the size of programme most institutions run. As a starting point for a call of a few hundred submissions and a jury of a few dozen:

• A current long-term-support Linux distribution, 64-bit
• 4 CPU cores and 8 GB of memory; 2 cores and 4 GB will run it with less headroom
• 100 GB of disk, sized mostly by attachments: decks run to a few megabytes each
• Outbound HTTPS, and inbound 443 from wherever applicants will reach it
• A DNS name, or a path under an existing one

Load is uneven: a call is quiet for three weeks, then takes most of its submissions and uploads in the final six hours. Size for that afternoon, not the average.

Step 1: prepare the virtual machine

1. Provision the VM on your standard institutional image, with your own patching and monitoring agents.
2. Create a dedicated service account. Nothing here needs to run as root beyond the initial install.
3. Create the attachment store and the database data directory on a volume with a backup policy, separate from the application directory.
4. Open inbound 443 only. The API service and the database listen on loopback, reachable only through the reverse proxy.
5. Set the system time zone and confirm NTP is running. Deadlines are enforced against server time, and a window that closes an hour late is a dispute.

Step 2: choose Docker or Apache with PM2

Two shapes are supported. Choose by what your team already runs, not by which is newer.

Docker. The application and API ship as container images. Choose this if your team already operates containers: dependencies are pinned in the image, upgrades are a tag change, rollback is the previous tag. You still need a reverse proxy in front and the attachment volume mounted from the host.

Apache with PM2. Apache serves the built front end as static files and reverse-proxies the API; PM2 supervises the API process and restarts it on failure and at boot. Choose this if your institution standardises on Apache and does not run containers. It is the shape the first institutional deployment uses.

Either way, record it in your runbook with the paths, the service account and the restart command. The commonest outage here is a reboot after which nobody is sure what was meant to start.

Step 3: provision MongoDB

MongoDB can run on the same VM or on an existing institutional database service.

1. Create a dedicated database and an application user with access to that database only.
2. Bind it to loopback on the same machine, or to a private interface if it is not. It should never be reachable from outside.
3. Enable authentication. An unauthenticated database on a machine believed to be internal is the commonest way institutional data leaves an institution.
4. Apply encryption at rest at the volume or database layer if your policy requires it.
5. Take and restore a dump before the application holds real data. A backup you have never restored is not a backup.

Step 4: serve under a base path

Most institutional deployments sit under an existing domain at a path, for example https://example.ac.in/innovation. Two things follow.

The front end must be built for the base path: asset URLs and client-side routes resolve against it, so a build made for the root loads a blank page under a path. It is set at build time, so tell us the path before the package is produced.

The reverse proxy routes everything under that path: static files for the application, the API prefix through to the API service. Preserve the prefix when proxying unless your configuration strips it and the API expects that — pick one convention and write it in the runbook.

Test with a hard refresh on a deep link, not only from the landing page. A deployment that works when you navigate and fails when you reload is a proxy rule, not an application fault.

Step 5: terminate TLS

Terminate TLS at the reverse proxy or at your institutional edge, whichever your policy prefers. Redirect all HTTP to HTTPS and serve the application only over HTTPS: sign-in, magic-link sign-in for applicants and file uploads all carry data that must not travel in clear text. Use the certificate your institution already issues for the domain, and if it renews automatically, confirm the renewal hook reloads the proxy.

Step 6: back up

Back up three things, on a schedule, somewhere that is not this machine.

1. The database, daily when quiet and hourly during an open window.
2. The attachment directory, on the same schedule. A database restored without the decks it references is broken, not partial.
3. The configuration — proxy rules, service definitions, environment settings — into your configuration management or version control.

Retain enough history to recover from a fault discovered a week later, in line with your policy. Then rehearse a restore onto a scratch VM before the first call opens and note how long it took. That number is your real recovery time.

Step 7: upgrades

Upgrades arrive as a new deployment package with release notes and any migration steps stated explicitly. The sequence is the same for both shapes: read the notes, take a fresh database and attachment backup, deploy to a staging copy if you keep one, apply any migration, restart the service, then check sign-in, one submission view and one scoring view before you tell anyone it is done.

Schedule upgrades between calls. An open window is not a maintenance window, and an evaluation deadline is worse.

Automatic in-place updates are not part of the self-hosted deployment. Upgrades are a scheduled task your team owns; release notes state any migration steps, and we will tell you when a release matters.

Checklist before you hand over

• VM on the institutional image, with patching and monitoring agents
• Dedicated service account, nothing running as root
• Data directories on a backed-up volume, separate from the application
• Only 443 inbound; API and database on loopback or a private interface
• Time zone correct, NTP running
• Deployment shape documented and confirmed to start after a reboot
• MongoDB authenticated, bound privately, dump and restore tested
• Base path agreed, front end built for it, deep link hard-refreshed
• TLS terminated, HTTP redirected, renewal reloads the proxy
• Database, attachments and configuration backed up off the machine
• One restore rehearsed, recovery time written down
• Runbook handed to a named owner and deputy