Customer Ownership and Installation Options

Who this document is for: enterprise and solution architects, IT infrastructure leads, security and compliance reviewers, and the technical decision-makers who have to answer two questions before a project management platform can be approved:

What exactly are we buying, and where does it run?

This document answers both. It is deliberately explicit about hardware, skills, effort and the assumptions behind each option, so you can size the commitment before committing to it rather than after.

Contents

1. What the platform is
2. The two questions: ownership, and hosting
3. Option A — Subscribe: use the hosted service
4. Option B — Managed containers on your infrastructure
5. Option C — Own the source code
6. Option D — Become a service provider
7. Where it runs: cloud, on-premises, air-gapped
8. Third-party services, licences and users
9. Side-by-side comparison
10. Choosing: a decision path
11. Why this architecture carries little long-term risk
12. Moving between options
13. Support and contact

1. What the platform is

The Timebars suite covers three project management disciplines from one codebase. All three products are runtime-configurable — a single deployment serves all three simultaneously, switched per user by a setting.

Two architectural facts shape every option below, and are worth stating up front because they are unusual:

The client application is browser-local. Project data lives in the browser's own IndexedDB database. The application works fully offline — no server round trip is required to open a plan, drag a bar, or run a report. There is no application server in the data path for day-to-day work.

Everything else is optional. The backend, the cloud dashboard, publishing and notifications are additional services you may or may not deploy. A user with only the client application has a complete, working product; they simply do not have team sharing or cloud dashboards.

The practical consequence for an architect: the deployment footprint is small, and the blast radius of a server outage is limited. If the backend is down, planners keep working.

Plans are files you keep, like a Microsoft Project .mpp. The application writes full backup files to the user's Downloads folder automatically (before every import and sync, and whenever the user asks) and syncs plans to spreadsheets. Those files go into your document management system alongside your other project records. See the Data Synchronization, Backup, Recovery and Retention guide.

2. The two questions: ownership, and hosting

Most vendor evaluations conflate these. Keep them separate and the choice becomes straightforward.

Question 1 — What do you acquire?

Four answers, in increasing order of control and of commitment:

Question 2 — Where does it run?

Options B and C both run wherever you choose: your public cloud tenancy, a VPS, your own data centre, or a fully air-gapped network. The suite has no proprietary infrastructure dependency and no phone-home licensing — licences come from the backend (Strapi) that you run yourself, or from a licence file (section 8.1) — so hosting is genuinely your decision rather than a menu the vendor controls. Section 7 covers this. Some optional features do call third-party services (AI, notifications, email, payments); section 8 lists them so you can decide which to keep.

The two questions are independent. Choosing Option B does not commit you to a cloud provider, and choosing Option C does not oblige you to run your own metal.

3. Option A — Subscribe: use the hosted service

The zero-installation option, and the right starting point for most organisations even if they intend to end up elsewhere.

Users run the client application from Timebars Ltd.'s hosted site. Project data stays in their browser. When a team needs to share, they publish a dataset to the Timebars Cloud, which feeds the Personal and Enterprise Dashboards and drives notifications.

What you get

• The three client applications, no installation
• Timebars Cloud publishing and dashboards
• Text notifications (each recipient installs the Pushover app, a small one-time purchase)
• Ask AI features, run through Timebars Ltd.'s AI service (Google Gemini); you log in with your Timebars Cloud account
• Updates and fixes as they ship, with nothing for you to deploy

You do not need any of the third-party accounts in section 8 — Timebars Ltd. operates them.

What to check before choosing it

• Published datasets are stored on Timebars Ltd. infrastructure. If your data residency, classification or procurement rules prohibit that, publishing is the part that will not pass review — the client application itself still holds data only in the user's browser.
• Cross-device access depends on publishing, so a policy against it also removes that convenience.
• Text you send to Ask AI is processed by Google Gemini through Timebars Ltd.'s AI service. If your policy does not allow that, do not use Ask AI.

Effort: none. Team: none. Time to first use: minutes.

Use it to evaluate, whichever option you expect to land on. It costs nothing in infrastructure and lets your PMs assess the product properly while the architecture review runs in parallel.

4. Option B — Managed containers on your infrastructure

Timebars Ltd. builds, tests and publishes versioned Docker images. Your team pulls them, deploys them to your infrastructure, and runs the environment. Application code is maintained by Timebars; infrastructure, configuration and operations are yours.

This is the right choice when the platform must run inside your perimeter and you do not want to allocate a development team to it.

What Timebars Ltd. delivers

• Pull access to the private images, granted to your own Docker Hub account (you log in with your own read-only access token — Timebars Ltd. does not share its credentials)
• The same images every customer runs: your addresses are settings, not a custom build
• The installation package (tbown), Container Option V2: you fill in one settings file (tbapps.conf) and it makes a ready package per environment (DEV, STAGING, PROD, TRAINING), each for its own server, with the Docker Compose stacks, a built-in HTTPS proxy, install / backup / restore scripts, seed data and a step-by-step deployment guide
• Environment configuration templates
• Setup and configuration documentation
• Ongoing image updates covering minor fixes and stability improvements (new product features are not included in the standard agreement)
• Custom feature development under a separate professional services engagement

The three containers

A deployment is these three containers plus a database (the public PostgreSQL image, or a managed PostgreSQL service).

A fourth container, jimecox807/tbhelpapp, is the AI service: it runs Ask AI, AI Create and the help assistant, keeps your Gemini key on the server and answers only logged-in users. It is needed only if you want the AI features; the app reaches it over a private Docker network, so it needs no public address. One optional image is also available, jimecox807/nwi (a sample customer portal), which the products do not need.

In front of them the package runs a proxy (the public Caddy image) that answers every address over HTTPS with free Let's Encrypt certificates. If you already run a reverse proxy with your own certificates, use that instead.

You also choose which third-party services to connect — AI, notifications, email, payments. Each needs your own account and keys (section 8). Without them the core products still run; those features stay off.

System requirements

Hardware — minimum for production

• 2 CPU cores
• 4 GB RAM
• 100 GB SSD
• Internet access for the initial image pull (see air-gapped for the alternative)

Software

• Docker Engine 24+ with the Compose v2 plugin (docker compose)
• Ubuntu 24.04 or 26.04 LTS, one server per environment (the package's scripts are written for Ubuntu). The images are Linux containers; Windows and macOS are suitable for evaluation, not production hosting
• PostgreSQL 14+ — a container, or a managed database service (the seed data is a PostgreSQL 14 dump and restores into 14 or newer)

Network

• Ports 80 and 443, plus any you configure
• DNS for your domain names
• TLS certificates: the package's proxy gets them from Let's Encrypt, or use your own

Team and skills

Initial deployment — 1 to 2 people, 4 to 8 hours

A DevOps engineer or systems administrator covering: Docker and Docker Compose, DNS and TLS, Linux or Windows Server administration, reverse proxy configuration (Nginx, Apache or Traefik), and environment variable management.

A database administrator is optional but recommended for production — PostgreSQL setup, backup procedures and initial tuning, 2 to 4 hours.

Ongoing operations

Deployment outline

1. On a dev box, fill in tbapps.conf with each environment's addresses and run apply: one ready package per environment
2. Prepare one server per environment and send it its package
3. On the server: install Docker, log in to Docker Hub, paste your keys
4. Run deploy-all.sh: it makes the passwords, starts the database, backend, website, Cloud, app and proxy, and loads the seed data
5. Point DNS at the proxy and check every address with the supplied check script
6. Set your own Strapi admin password and API token, and your users
7. Schedule the nightly backup and your monitoring

What to weigh

• Application code and the feature roadmap remain with Timebars Ltd.
• Updates are a pull and a restart of the affected containers
• Customisation is configuration only — the application code is not accessible. New hostnames need an image built for you by Timebars Ltd.
• In an air-gapped network, Ask AI and notifications are not available with Option B, because connecting them to internal systems needs code changes (Option C)
• Receiving updates requires Docker Hub access, which matters for air-gapped sites

5. Option C — Own the source code

The complete source, delivered once as a copy for your own Git host, plus the build and deployment scripts Timebars Ltd. uses. Your development team builds the applications, sets up its own pipeline, and operates production. You own the product.

Choose this when you need to modify the platform itself — scheduling logic, data model, UI, integrations, reporting — or when operating independently of a vendor's roadmap is itself the requirement.

What Timebars Ltd. delivers

• Time-limited read access to the GitHub repositories so you can clone them (VS Code is the recommended tool), then push the copy to your own Git host — GitHub, GitLab, Bitbucket or an internal server
• Docker Compose configuration and deployment scripts
• Environment configuration templates for every component (variable names only — you generate your own secrets)
• Setup and configuration documentation, including the Administrators Guide
• A supervised handover of the third-party services in section 8: Timebars Ltd. shows you its configuration and you copy what you need (settings) into your own accounts
• Custom feature development under a separate professional services engagement

The code is a one-time delivery. After handover, updates, security patches and dependency upgrades are yours; further fixes from Timebars Ltd. are by separate agreement.

The repositories

The deployment pipeline

A standard three-zone pattern any experienced engineer will recognise on sight.

Zone 1 — Development. Your team works the source, builds features, and validates against a local staging environment before anything advances. Commits go to your own Git host — GitHub, GitLab or Bitbucket.

Zone 2 — CI to a registry. Every push triggers your pipeline: build the images, run lint and tests, push tagged versions to your registry. This is the controlled handoff. Nothing reaches production without passing it.

Zone 3 — Production. The production host pulls the current image and runs the applications as containers, behind a reverse proxy handling routing and TLS, with PostgreSQL persisting data. AWS, GCP, Azure, Hetzner, DigitalOcean or bare metal — no proprietary dependencies and no vendor-controlled infrastructure in the path.

AI-accelerated customisation

The codebase is structured and documented to be navigable by AI coding tools. This materially changes the economics of owning it: a team can orient in an unfamiliar codebase far faster than by traditional review, implement targeted changes to scheduling logic or data models in days rather than weeks, and generate tests alongside features.

The practical result is that a small, capable team can have a working customised version in days to a few weeks, depending on how deep the modifications go — without needing deep expertise in every layer before they start.

System requirements

Hardware — minimum for production

• 2 CPU cores
• 4 GB RAM
• 100 GB SSD (builds run on your developers' machines, not the production host)

Software

• Node.js 22 LTS (the version the client application builds with), NPM, Git
• Docker Engine 24+ with the Compose v2 plugin
• PostgreSQL 14+
• A currently supported Linux server release for production; any OS for development

Build tooling (included in the repositories) — Parcel for tbrunp, Next.js build tooling for tbwww, Strapi build dependencies for tbbe.

Team and skills

Initial deployment — 2 to 4 people, 24 to 48 hours

Ongoing operations

Deployment outline

1. Clone the repositories and push them to your own Git host
2. Install Node.js, NPM and dependencies
3. Configure environment variables per component
4. Provision and configure PostgreSQL
5. Create your own third-party accounts for the services you keep (section 8)
6. Build each component — tbrunp (Parcel), tbwww (Next.js), and tbbe (Strapi)
7. Deploy to containers or directly to web servers
8. Configure reverse proxy routing and TLS
9. Stand up your CI/CD pipeline
10. Test across all three products
11. Configure monitoring, logging, alerting and backups

What you gain

Complete control. Data models, scheduling logic, UI, reporting, integrations — all modifiable. No vendor feature flags, no API rate limits, no roadmap dependency.

One-time acquisition. No per-seat fees and no subscription that grows with headcount. Ongoing cost is your own team's time.

Data sovereignty. The application runs entirely on your infrastructure. Data transits a third-party service only where you choose to connect one — AI, notifications, email or payments (section 8) — and you can replace or remove each of those.

White-label ready. The codebase can be rebranded for internal deployment or integration into a broader offering. Selling the products to other organisations as a service is Option D.

No vendor sunset risk. When you own the source, the product cannot be discontinued beneath you. This is not theoretical — Microsoft is retiring the cloud-based Project Online on 30 September 2026, forcing its users into migrations they did not choose on a timeline they did not control. (The on-premises Project Server Subscription Edition is not affected and is supported until at least 31 December 2031.) Pricing changes, acquisitions or discontinuation at the vendor level have zero impact on a deployment you own.

A proven foundation. The scheduling engine, data structures and spreadsheet integration are production-tested. Your team customises a working product rather than speculating about whether a complex scheduling system can be built.

What to weigh

• Your team owns all updates, security patches and dependency maintenance
• Build expertise across Node.js, Next.js, Strapi and Docker is required
• The source carries Timebars Ltd.'s own service addresses (website links, OpenProject default). Your team replaces them with yours as part of setup
• Initial setup is more involved than Option B — budget for the pipeline and testing phases specifically
• Depth of customisation drives the timeline. A straightforward deployment moves quickly; significant workflow modification does not

6. Option D — Become a service provider

Options A to C are for organisations that use the products themselves. Only Timebars Ltd. sells subscriptions to the products. An organisation that wants to offer Agilebars, Timebars and Costbars to its own customers as a paid service needs a special arrangement with Timebars Ltd.

What it is: Option C — the complete source, delivered once — plus the right to run the sales site, take payments and issue licences to other organisations. As part of the arrangement Timebars Ltd. retires its own hosted service.

What it adds to Option C

• The sales and sign-up site (tbwww) with Stripe payment processing, so customers can buy and renew subscriptions online
• Licence issuing through Strapi (orders and products), including tiers and limits
• Notifications, email and dashboards run for many customer organisations, not one
• Your own support, billing, terms of service and privacy obligations to your customers

What to weigh

• You become the vendor: uptime, security, data protection and support for other organisations' data are your responsibility
• A Stripe account, tax set-up and the commercial terms are yours
• Plan this with Timebars Ltd. from the start — the handover of the running service is planned together

7. Where it runs: cloud, on-premises, air-gapped

Options B, C and D impose no hosting constraint. The stack is containers, a reverse proxy and PostgreSQL — a shape every hosting environment supports.

Public cloud

Google Cloud, AWS, Azure, DigitalOcean (which Timebars Ltd. uses for its own service) or any VPS provider. Run PostgreSQL as a container or use the provider's managed database service — RDS, Azure Database for PostgreSQL, Cloud SQL — whichever your organisation already standardises on. Nothing in the application depends on a particular provider's services.

Your own data centre

The same stack on your own hardware or virtualisation platform. The minimum production footprint is modest enough — 2 cores, 4 GB RAM, 100 GB SSD — that it usually fits existing capacity rather than requiring a purchase.

Hybrid

Because the client application is browser-local, a common arrangement is to run the backend and dashboards centrally while planners work entirely in their browsers, syncing on their own schedule. Server outages do not stop planning work.

Air-gapped and restricted networks

Options B and C both run in environments with no internet access, restricted perimeters, or policies against third-party vendor dependencies. Option C is the better fit for an air-gapped network, because the features that normally use an internet service can be reconnected to internal systems only by changing code.

Once the images or source have been delivered and your environment is configured, the suite runs entirely on your infrastructure with no ongoing external connections required for planning, reporting, publishing, dashboards and login. There is no phone-home licensing mechanism and no vendor system in the data path: licences are read from the Strapi backend you run on your own network, or from a licence file (section 8.1).

Features that depend on an internet service need an internal equivalent:

The one operational consideration: updates have to be carried in. For Option B that means transferring new images across your boundary by whatever controlled process you already use; for Option C, the repository updates. Neither requires a live connection from the running system.

Organisations with data residency obligations, government or defence network constraints, or internal policy requiring full infrastructure independence can deploy with confidence — Option C where AI or notifications are required inside the gap.

8. Third-party services, licences and users

The platform is built from open-source software plus a small number of external services. For Option A you need none of these — Timebars Ltd. runs them. For Options B, C and D, this is the full list, so you can decide which to keep, replace or leave off. Every service you keep runs under your own account and keys: Timebars Ltd. never shares its logins, and you should not run production on another organisation's account. The Administrators Guide has the set-up steps for each.

Questions to settle in your architecture review:

• Which data leaves your network? Ask AI sends prompt text and project context to Google Gemini; notifications send project names and status to Pushover or Twilio; registration email sends addresses to SendGrid.
• Who pays and who owns the account? Each service bills the account holder.
• What replaces a service you leave off? Most have a self-hosted or internal alternative, noted above.

Ask AI runs on your own server. The AI features run in the helpapp container on your own server. The Gemini key (or your own model) is configured there only, and requests are accepted only from users logged in to your Timebars Cloud (Strapi). Sites with no Strapi can switch that check off and keep AI reachable from their own network only.

8.1 Licences and users

Every user of the client application needs a licence: the product (Agilebars, Timebars or Costbars), the tier, the limits and an expiry date. There are two ways to deliver it.

With Strapi (the standard way). Your administrator adds each user in the Strapi backend and gives them an order — product, tier, expiry. The user logs in once in their browser and the licence is loaded. Strapi also provides publishing, the dashboards and notifications, and lets you renew or revoke licences centrally.

Without Strapi (licence by email). If you only need the planning application — no publishing, dashboards or notifications — you can leave Strapi out entirely. Each user receives a small licence file by email and imports it once in the application. Renewal is a new file before the expiry date. (Licence-file import is being added to the product; until it ships, a deployment without Strapi shows as unlicensed.)

Who issues the licences:

• Option B: whoever runs Strapi controls its licences, so an Option B purchase covers your organisation as a whole. Without Strapi, Timebars Ltd. issues signed licence files.
• Option C: you own the code, so you choose — run Strapi, issue your own licence files, or remove the licence checks altogether.
• Option D: you issue licences to your customers through Strapi and Stripe.

9. Side-by-side comparison

10. Choosing: a decision path

Work down this list. The first "yes" is usually your answer.

1. Must the data never leave your infrastructure? Rules out Option A's publishing features. Go to B or C.

2. Do you need to modify the product itself — scheduling logic, data model, integrations with internal systems, or a white-labelled build? Option C. Nothing else provides it.

3. Is independence from vendor roadmap and vendor survival a stated requirement — for procurement, compliance, or long-term risk policy? Option C. Owning the source is the only structural answer.

4. Must it run inside your perimeter, but standard functionality is sufficient? Option B. You get the deployment control without the development commitment.

5. Do you want to sell the products to other organisations as a service? Option D, by special arrangement with Timebars Ltd.

6. None of the above? Option A. Start there. It costs nothing in infrastructure, and you can move later.

A recommended sequence

Most organisations that end at B or C are better served by getting there in two steps rather than one:

1. Evaluate on Option A while the architecture review runs. Your PMs assess whether the product fits how they actually work — which is the question that decides everything, and the one an architecture review cannot answer.
2. Deploy B or C once the product is proven and the requirement is clear.

The reverse order — standing up infrastructure before anyone has confirmed the product suits the team — puts the expensive step first.

11. Why this architecture carries little long-term risk

Architects reviewing a platform properly ask what happens in five or ten years. Three answers:

Built on the open web stack. JavaScript, HTML and CSS running in a browser. Not a proprietary runtime, not a vendor-controlled framework, not a platform-specific technology. JavaScript is the most widely used programming language in the world, browsers are permanent infrastructure, and the standards are governed by open industry bodies. There is no realistic path to deprecation.

PostgreSQL, with no licensing exposure. Over 35 years of active development, governed by an independent community and a non-profit association. No single company owns it; no vendor can change its licensing or discontinue it. Consistently among the top four databases globally, used in production by Apple, Instagram, Spotify and thousands of enterprises. No per-core fees, no enterprise-edition paywall, and a large global talent pool.

Containers and a reverse proxy. The deployment pattern is the industry default. Any engineer you hire in the next decade will recognise it.

The combination means the skills to run this are the skills your team already has or can readily hire, and none of the foundations depend on the commercial survival of a particular vendor.

12. Moving between options

The options are a progression, not a lock-in, and movement is supported in both directions.

Timebars Ltd. provides migration assistance between options if requirements change. Because data moves as standard JSON and spreadsheet formats, no proprietary export step is involved.

13. Support and contact

All options include:

• Deployment documentation
• Configuration templates and environment examples
• Technical support during initial setup
• Knowledge base access
• Migration assistance between options

For technical questions, onboarding support, or to discuss a specific deployment:

Jim Cox Timebars Ltd. Phone: (613) 255-5374 Email: [email protected]

Related documents

Supersedes: Customer Installation Options, and Products Installation For On Prem.