# MapleDeploy — Published Non-Legal Content > This file contains the published non-legal text content of mapledeploy.ca for AI answer engines. --- ## About MapleDeploy MapleDeploy is a Canadian-owned hosting platform run from Toronto. Learn who builds it, why it exists, and how the business behind it operates. URL: https://mapledeploy.ca/about {% hero-section title="About MapleDeploy" %} A Canadian hosting platform built by a developer in Toronto. Here's who runs it, why it exists, and how the business behind it operates. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Deploy a real project, see if it fits {% /button %} {% /hero-section %} {% intro-section %} MapleDeploy provides managed Coolify hosting on dedicated Canadian servers. It exists for a simple reason: every popular deployment platform is a US company on US infrastructure, and a Canadian alternative didn't exist. MapleDeploy is that alternative. {% /intro-section %} {% content-section title="Why MapleDeploy exists" %} It started as a personal problem. I wanted to run my own projects on [Canadian infrastructure](/canadian-hosting), with the git push workflow I was used to. That option didn't exist. Every developer-friendly platform routed through US companies subject to the **US CLOUD Act**. So I built the platform I was looking for, then opened it up to other Canadian developers and businesses that want the same thing. I use it for my own projects every day, so I have a direct stake in keeping it fast and reliable. When you email, you're talking to the developer who built the platform and runs the servers. No ticket queue, no support tiers. {% signature %} – [Ross Hill](https://rosshill.ca) {% /signature %} {% /content-section %} {% content-section title="The business" %} MapleDeploy is a service of **Lawrence Digital**, a sole proprietorship registered in Ontario, Canada. It is wholly Canadian-owned, with no US parent company and no foreign investors. Our [Canadian ownership verification](/legal/canadian-ownership) has the corporate details. Your server is a dedicated VM in a Toronto data center, run by a privately owned Canadian infrastructure provider. The platform layer is [open-source Coolify](/open-source-stack), managed for you. Our [data residency attestation](/legal/data-residency) documents exactly where your data lives. {% /content-section %} {% info-card-section title="How we operate" %} {% info-card title="Canadian by default" %} Your application data stays in Canada on every plan, governed by Canadian law and designed for PIPEDA compliance. It's the default, not an add-on. {% /info-card %} {% info-card title="Transparent stack" %} No proprietary black boxes. MapleDeploy runs on open-source Coolify and documented Canadian infrastructure. Every layer is visible and verifiable. {% /info-card %} {% info-card title="Flat pricing" %} From $45 CAD/month for a dedicated VM. Run multiple apps and databases on one server. No per-project fees, no egress billing. {% /info-card %} {% info-card title="No lock-in" %} Coolify is open source under the Apache 2.0 license. If you ever want to leave, you can self-host the same stack on your own servers. {% /info-card %} {% /info-card-section %} {% cta-section title="Get in touch" hide-button=true %} Questions about the business, compliance, or whether MapleDeploy fits your project? We're happy to answer. {% button href="mailto:hello@mapledeploy.ca" variant="secondary" %} Contact us {% /button %} {% /cta-section %} --- ## An experimental guide to technical AEO The technical side of AEO: content delivery format, llms.txt, and metadata. Not a content strategy guide, and nobody knows the final playbook yet. URL: https://mapledeploy.ca/blog/answer-engine-optimization-guide Date: 2026-04-01 [About 68% of Google searches](https://sparktoro.com/blog/in-2026-less-than-one-third-of-google-searches-still-send-a-click/) ended without a click in early 2026. [AI referral traffic to major websites grew 357% year over year](https://web.archive.org/web/20260725222245/https://www.similarweb.com/blog/insights/ai-news/ai-referral-traffic-winners/) in 2025. When someone asks ChatGPT or Perplexity "what's the best Canadian hosting platform," the answer may come from whatever the model already knows, or whatever it can fetch in real time. That changes the job of a marketing site. It still needs to rank, load quickly, and convert humans. But it also needs to be easy for AI systems to read, summarize, and cite accurately. That is **answer engine optimization (AEO)** in practice. Not a guaranteed traffic channel, just making your content easier for answer engines to understand. This covers the technical delivery side: content format, routing, and metadata. Content strategy, keyword research, and what to write are separate problems. Fair warning: the standards here are still experimental. `llms.txt` and the IETF AI preference drafts are still proposals, and I cannot measure a direct lift in AI citations yet. I tried this anyway because the direction seems real, and the changes also made the site easier to maintain. ## What I changed I rebuilt the content pipeline around four ideas: 1. Keep source content in markdown. 2. Publish an `llms.txt` index. 3. Serve markdown when a client explicitly asks for it. 4. Add enough metadata for AI systems to identify the business and cite pages correctly. You do not need to copy every implementation detail. The useful pattern is simpler: make the authoritative content available as clean text, then point agents to the right place. ## Keep source content in markdown A browser can handle a deeply nested React page. An answer engine often wants the text, headings, links, and facts as directly as possible. Moving page content into markdown gives you that clean source. Your rendered site can still use React components, custom sections, feature grids, and calls to action. The source file just becomes easier for both humans and tools to inspect. For MapleDeploy, [Markdoc](https://markdoc.dev/) was a good fit because it lets us keep markdown as the source while mapping custom tags to React components at render time. MDX can solve the same problem. The specific tool matters less than the outcome: the page content lives in a text format that is readable before the browser renders anything. That also gives you a better internal source of truth. Blog posts, comparison pages, docs, and landing pages can all be indexed, transformed, and served from the same content directory. ## Add llms.txt The [llms.txt](https://llmstxt.org/) convention is a text file at `/llms.txt` that gives AI systems a curated map of your site. Think of it as a table of contents for language models. A sitemap says "these URLs exist." An `llms.txt` file says "this is who we are, these are the pages that matter, and this is where to go for more detail." A useful `llms.txt` includes: - A short description of the site. - Key product pages. - Important comparison pages. - Blog posts worth citing. - A link to full markdown content if you publish one. We also publish `/llms-full.txt`, which combines the markdown body of published content into one response. That gives research agents a single place to fetch complete site context. Keep both files generated from your content source. Filter out unpublished posts, and cache the result so it is cheap to serve. ## Serve markdown on explicit request Once the content source is markdown, give clients a predictable way to request it. There are two useful triggers: - `Accept: text/markdown` - A `.md` version of the URL, such as `/canadian-hosting.md` The important word is explicit. I would not serve markdown based on user-agent sniffing. AI tools, browsers, crawlers, and preview clients all change their user agents over time. If a client asks for HTML, serve HTML. If it asks for markdown, serve markdown. You can verify the behaviour with simple requests: ```bash curl -H "Accept: text/markdown" https://yoursite.com/some-page curl https://yoursite.com/some-page.md ``` For `.md` URLs, add a canonical `Link` header that points back to the HTML page. That tells search engines which version is authoritative and avoids treating the markdown copy as a competing page. ## Add useful metadata Markdown is clean, but a single markdown page can lose context. An HTML page has meta tags, OpenGraph properties, canonical links, and structured data. A markdown response should carry the same basic facts. For MapleDeploy, the markdown response includes page frontmatter plus site-level metadata such as: - Site name - Locale - Canonical URL - Author - Business region - Pricing summary - Link to `/llms.txt` The goal is not to stuff keywords into the response. The goal is to remove ambiguity. If an answer engine fetches a page and needs to answer "what does this company do?" or "what does it cost?", it should not have to guess. Keep this metadata in the served response, not necessarily in every raw source file. Page-specific frontmatter should remain readable for authors. On the HTML side, keep using JSON-LD structured data where it fits: `Organization`, `Article`, `BreadcrumbList`, or product-specific schema. Google dropped FAQ rich results in 2026, though `FAQPage` markup is still valid and still parsed by AI retrieval systems. Traditional search and AI retrieval both benefit from clear structure. ## Set permissions clearly Making content easier to fetch is one decision. Saying what systems can do with it is another. At minimum, keep `robots.txt` intentional. If you are open to crawling, a normal wildcard allow rule is enough. If you want to block specific crawlers, robots.txt is where that policy belongs. For more granular signals, the [IETF AI Preferences drafts](https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab) are still in flux. The [attachment draft](https://datatracker.ietf.org/doc/draft-ietf-aipref-attach/) defines a `Content-Usage` header. We send the opt-in form, since we want answer engines reading and citing this content: ```text Content-Usage: train-ai=y, search=y ``` The draft also defines `train-ai=n` if you want to signal the opposite. Adoption is early, so treat this as a signal, not enforcement. The practical value is that your intent is clear. ## What I would skip I would skip anything that depends on guessing bot identities. It is brittle and easy to get wrong. I would also avoid overbuilding metrics too early. Watch logs for `/llms.txt`, `/llms-full.txt`, `.md` URLs, and `Accept: text/markdown` requests. That tells you whether tools are using the paths. It does not prove that the work is improving citations or revenue. Finally, do not make the markdown version worse for humans just to satisfy a theory about AI. Clear headings, short paragraphs, accurate links, and factual copy help both audiences. ## Conclusion The whole pipeline is simple: write content in markdown, publish an AI-readable index, serve markdown when asked, and include enough metadata to keep citations accurate. Is all of this necessary? Nobody knows yet. The line between "website" and "document an AI can read" is getting thinner, but the winning standards are still unsettled. What I do know is that clean markdown content, useful metadata, and explicit routes are a better foundation than burying every important fact inside rendered components. If AI-mediated discovery keeps growing, the site is ready. If it does not, the content system is still cleaner than before. --- MapleDeploy is a managed [Coolify](/open-source-stack) hosting platform on Canadian infrastructure, with plans starting at $45 CAD/month and a 30-day free trial. If you're building something that needs Canadian data residency, [take a look](/#pricing). {% cta-section title="Canadian hosting, managed for you" %} Deploy on Canadian infrastructure with git push. Start with a 30-day free trial. {% /cta-section %} --- ## Is AWS ca-central-1 actually Canadian data residency? AWS ca-central-1 keeps your data in Montreal. That is geography. Jurisdiction is a separate question, and here is when the difference matters. URL: https://mapledeploy.ca/blog/aws-ca-central-1-data-residency Date: 2026-08-30 Deploy to `ca-central-1` and your data sits in Montreal. That part is real, contractual, and auditable. Whether it satisfies your data residency requirement depends on what that requirement actually says. A region is a geography setting. Jurisdiction is a corporate fact. Most data residency checklists treat them as the same thing, and they are not. This post is about that gap. It is not legal advice, and it is not an argument that hyperscaler Canadian regions are a bad choice. For plenty of workloads they are the right call. What follows describes public commitments and public testimony, with sources, so you can check them yourself. If a contract, a regulator, or a client questionnaire is driving your residency requirement, have qualified counsel read the actual wording before you act on it. ## What the hyperscalers actually offer in Canada All three major providers have Canadian infrastructure, and there is more of it than people assume. **AWS** runs two Canadian regions. Canada (Central), `ca-central-1`, opened near Montreal in December 2016. [Canada West, `ca-west-1`, opened near Calgary](https://aws.amazon.com/blogs/aws/the-aws-canada-west-calgary-region-is-now-available) in December 2023, making AWS the first major provider with a region in Western Canada. **Azure** runs Canada Central in Toronto and Canada East in Quebec City, both online since 2016. They are a paired region set, so you can replicate across them without leaving the country. **Google Cloud** runs `northamerica-northeast1` in Montreal, launched in 2018, and `northamerica-northeast2` in Toronto. These are real facilities with real Canadian addresses. Nobody is faking the geography. ## What a region guarantees AWS states the residency commitment plainly on its [Canada data privacy page](https://aws.amazon.com/compliance/canada-data-privacy/): AWS will not move your content outside your chosen region without your agreement, "except in each case as necessary to comply with the law or a binding order of a governmental body." That sentence is worth reading twice. The commitment is genuine. The exception at the end is the entire subject of this post. Storage location is a technical control. Whose law can compel disclosure is a different control, and the region dropdown does not touch it. ## Where the region setting stops The **CLOUD Act**, passed in the United States in 2018, gives US law enforcement a mechanism to compel American companies to produce data in their possession, custody, or control, regardless of where that data is stored. Amazon, Microsoft, and Google are US companies. Storing in Montreal does not remove them from US jurisdiction. We already wrote the detailed version of this, including what the law does and does not cover and why PIPEDA is not a defence against it. Read [the US CLOUD Act explainer](/blog/us-cloud-act-canadian-businesses) rather than taking our word for it here. A recent illustration came from Europe. On June 10, 2025, testifying under oath before a French Senate committee, Microsoft France's director of public and legal affairs, Anton Carniaux, [was asked whether he could guarantee](https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/) that French citizens' data would never be handed to US authorities without French approval. His answer was no, he could not guarantee it. He added that, to his knowledge, no such request had ever been made. Both halves of that answer matter. The exposure is structural, not hypothetical. On the evidence he gave, it has also not been exercised. Reasonable people weigh those two facts differently depending on what they are running. ## Sovereignty-branded offerings, and where they exist The hyperscalers know this is a live objection and have built products in response. Be precise about what each one changes. **AWS European Sovereign Cloud** changes the corporate structure, not just the controls. It became generally available in January 2026 and is [operated by German-incorporated entities](https://www.aboutamazon.eu/news/aws/built-operated-controlled-and-secured-in-europe-aws-unveils-new-sovereign-controls-and-governance-structure-for-the-aws-european-sovereign-cloud) under a separate governance model, with a first region in Brandenburg. It is a European offering. There is no Canadian equivalent. **Microsoft's sovereign solutions**, [announced in June 2025](https://blogs.microsoft.com/blog/2025/06/16/announcing-comprehensive-sovereign-solutions-empowering-european-organizations/), span a sovereign public cloud, a sovereign private cloud, and national partner clouds. Again, aimed at European organizations. **Google Cloud** does have a Canada-specific product. [Assured Workloads includes a Canada Data Boundary control package](https://cloud.google.com/assured-workloads/docs/control-packages/canada-data-boundary) that restricts data location to Canadian regions, with a Protected B variant that adds support from screened Canadian personnel. That is meaningful. It is a controls package layered on Google Cloud, not a change to which company is contracting with you. Personnel controls, customer-managed keys, and access justifications all narrow the risk surface. None of them change the incorporation of the entity that receives a subpoena. ## When a Canadian hyperscaler region is the right answer Plenty of the time. If your requirement is written as "data at rest must remain in Canada," a hyperscaler Canadian region satisfies it directly and gives you documentation to prove it. If you need multi-region failover inside Canada, all three providers let you do that today. If you need a specific managed service that only a hyperscaler operates, that is a real constraint and geography is what you get. Physical residency is a genuine requirement in many contracts, and it is genuinely met here. Do not let anyone tell you a Montreal region is meaningless. It is not. ## When jurisdiction is the actual requirement The distinction bites when the requirement is about legal control rather than physical location. - A client contract that asks which country's law governs access to their data, not just where it is stored. - A procurement questionnaire asking where your provider's parent company is incorporated. - An RFP that distinguishes "hosted in Canada" from "Canadian-controlled." - Your own preference, if you would rather your infrastructure answer to Canadian courts. That last one is not a compliance argument and does not need to be. Preferring Canadian jurisdiction is a legitimate reason on its own. The useful test is simple. Ask whether your obligation is satisfied by a map or by a corporate registry. If a map is enough, pick the region and move on. If someone is going to ask who can be compelled, the region setting will not answer them. ## What a Canadian-jurisdiction option looks like It looks like a Canadian-owned company running on Canadian-owned infrastructure, with no US provider in the path of your application data. MapleDeploy is [Canadian-owned and operated](/canadian-hosting). Customer VMs run on LunaNode, a privately held Canadian company incorporated in British Columbia ([Corporate Registry #BC0997033](https://opencorporates.com/companies/ca_bc/BC0997033)) that operates its own infrastructure in a Toronto data center. Each customer gets a dedicated VM running [managed Coolify](/open-source-stack), with git push deploys, automatic SSL, and one-click databases. Your application data, databases, and Coolify instance stay under Canadian jurisdiction. We are also honest about the boundaries. Payment processing runs through Stripe, a US company, for PCI reasons, and we offer Interac e-Transfer as a Canadian alternative. Uptime monitoring uses a US provider that sees server health status and no application data. Both tradeoffs are documented on our [sub-processors page](/legal/subprocessors) rather than hidden. Canadian jurisdiction is also not the same thing as a regulated-workload platform. Our [terms](/legal/terms) rule out several data categories entirely, including health and medical information, payment card data, and government-issued or financial account identifiers. If that is what you need to host, you need a provider that has signed up for those obligations. For a broader checklist on evaluating providers, including the questions worth asking before you sign, see [what actually matters in Canadian hosting](/blog/canadian-web-hosting-what-matters). The short version: `ca-central-1` is Canadian geography. Whether you also need Canadian jurisdiction is a question only your contracts, your clients, and your own judgement can answer. {% cta-section title="Canadian jurisdiction, not just a Canadian region" %} Dedicated VMs on Canadian-owned infrastructure in Toronto. Try Starter or Pro free for 30 days. {% /cta-section %} --- ## Building your SaaS on Canadian infrastructure What makes a product credibly Canadian, and how to assemble a stack that keeps your data out of US jurisdiction. URL: https://mapledeploy.ca/blog/build-canadian-saas Date: 2026-03-31 More Canadian developers are looking at their stack and asking a simple question: why is all of this in the US by default? For a long time the answer was "because that is where the good tools are." That is still partly true, but the gap is closing and the reasons to care have grown. For many developers, it comes down to preference. You live in Canada, you build in Canada, and you would rather your servers sit here too. Defaulting every new project to us-east-1 without a second thought starts to feel wrong. For others it is a business requirement: Canadian customers increasingly ask where their data lives before signing a contract. Both motivations point to the same stack. If you are a developer or entrepreneur thinking about building a Canadian alternative to a popular US web app, this is a good moment to take it seriously. ## Why now The conversation around **digital sovereignty** has moved from niche concern to mainstream policy. The federal government's [Direction on the Secure Use of Commercial Cloud Services](https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services/direction-secure-use-commercial-cloud-services-spin.html) and [data sovereignty guidance](https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services/digital-sovereignty.html) set Canadian residency expectations for sensitive government data. Provinces have their own rules. Quebec's [Law 25](/blog/quebec-law-25-data-residency) sets its own expectations for how personal information is protected and transferred outside the province. The underlying concern is the **CLOUD Act**, a [2018 US federal law](https://www.congress.gov/bill/115th-congress/house-bill/4943) that lets US authorities compel US-based providers to produce data regardless of where it is stored. If your hosting provider is a US company, your data is potentially reachable, even from a Toronto server. We cover [the full implications for Canadian businesses](/blog/us-cloud-act-canadian-businesses) in a dedicated post. This is not a hypothetical. For buyers with data residency requirements, documentation is increasingly a prerequisite before contracts get signed. Even for everyday business data, "where does it live?" is a reasonable question to answer clearly. ## What makes a product credibly Canadian Slapping a maple leaf on your landing page is not enough. Here is what you actually need to claim Canadian data residency with a straight face. **Hosting jurisdiction.** Your servers need to be in Canada, operated by a company not subject to US law. A US cloud provider with a Toronto availability zone does not count, because [jurisdiction follows the company, not the data center](/blog/why-we-chose-canadian-first-infrastructure). Options include LunaNode (Toronto, Canadian-owned) and OVH Canada (Montreal, French parent company, outside US jurisdiction). **Company incorporation.** Where your business is registered matters for contracts and liability, but it is a secondary concern compared to data location. Most Canadian customers care more about where the data lives than where your company is incorporated. **Data residency by design.** It is not enough for data to currently live in Canada. Customers want documented, enforceable assurances. This means a clear privacy policy, a data processing agreement for enterprise customers, and ideally a **PIPEDA** compliance attestation. [PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/) is Canada's federal private-sector privacy law, overseen by the Office of the Privacy Commissioner of Canada. Building to PIPEDA from day one is simpler than retrofitting it later. **Third-party services.** This is where things get complicated. Every SaaS you rely on is a potential data residency gap. Stripe, Twilio, SendGrid, Intercom, Sentry, and most of the popular developer tools are US companies. Using them does not automatically disqualify your product, but it requires transparency. If your app keeps customer records in Canada but streams detailed usage logs to a US analytics platform, you need to explain that. If card details go directly to Stripe, that is a different tradeoff because Stripe handles the payment flow and the data does not pass through your application servers. The honest answer is that going fully Canadian is hard and sometimes has real tradeoffs. Fewer choices, sometimes higher prices, occasionally weaker tooling. We are transparent about that with our own stack. ## The tradeoffs Smaller ecosystem. Some categories of tools simply do not have good Canadian alternatives yet. Observability, error tracking, feature flags, and A/B testing tooling are largely US-controlled. You will face a choice: use a US tool with strict data minimization, find an EU-headquartered alternative, or build the capability yourself. Cost. Canadian infrastructure tends to be slightly more expensive than equivalent resources from AWS or Google Cloud in US regions. Not dramatically more, but it is a real factor. Compliance is ongoing, not a checkbox. PIPEDA compliance is not something you achieve once. It requires a privacy policy that is actually accurate, a process for handling data requests, and consistent practices across your team. These tradeoffs are worth knowing upfront. Building Canadian should be a considered choice, not an afterthought. ## Categories worth watching There is genuine demand for Canadian alternatives in several areas. Client portals, internal tools, project management, collaboration, agency workflows, and legal operations are all practical places to start. Some sectors need specialized contracts and controls before a provider is appropriate. But many Canadian organizations use US tools like Notion, Slack, or Asana for everyday work and accept that data is in the US. Some are starting to look for alternatives. Developer tools are a growing category. Build servers, deployment platforms, and internal tooling are increasingly subject to the same procurement scrutiny as user-facing software. We are not going to tell you exactly what to build. But if you are evaluating a product idea, think about who would actively look for a Canadian option. Some are compliance-driven buyers who cannot approve the US version of your product. Others are developers and founders who simply prefer to keep their stack on Canadian infrastructure. Both are real markets. ## Assembling a Canadian stack Here is how we think about a credibly Canadian deployment stack: **Hosting.** This is the foundation. Your compute, your databases, and your file storage all need to live on Canadian infrastructure with a non-US provider. [Canadian infrastructure](/canadian-hosting) is the non-negotiable part of the stack. **Deployment platform.** You need something to manage deployments, run containers, and provision databases. Rolling your own on bare metal is painful. A managed platform that runs on your own Canadian VM is a practical middle ground. MapleDeploy provisions a dedicated VM in Toronto (via LunaNode) and installs [Coolify](/open-source-stack) on it. You get git-push deploys, managed databases, SSL, and reverse proxying, all running on infrastructure that is yours. It is a Canadian alternative to Heroku, Railway, [Render](/compare/render), Vercel, and other US platforms, purpose-built for teams that want jurisdiction and not just geography. Plans [start at $45 CAD/month](/#pricing) for a 4 GB RAM / 2 vCPU server with flat pricing and no per-app fees. **Email.** Transactional email is tricky. SendGrid and Postmark are US companies, and Mailgun operates as a US entity under Swedish parent Sinch, so it carries the same US jurisdiction exposure. Cakemail is a Canadian option based in Montreal. For business email, Mailbox.org is Germany-based. Neither is perfect if you need everything in Canada, but both are better than routing everything through AWS SES. **Payments.** Stripe is a US company. We wanted to use Helcim, a Calgary processor with a solid subscription API, but their acceptable use policy rules out managed hosting. Card details are handled by Stripe under their own PCI compliance framework and do not pass through our servers. We wrote about [our reasoning and what we tried](/blog/why-we-use-stripe). For most products, this is an acceptable gap. For some, it is not. **Open source where possible.** Open-source software with self-hosted deployments keeps your data local by default. We built on [Coolify](/open-source-stack), which is open source and runs entirely on your VM. The same logic applies to databases (PostgreSQL, MySQL), analytics (Plausible, Umami), and monitoring (Grafana). ## Where MapleDeploy fits We are the deployment and hosting layer. We provision and manage Coolify instances on LunaNode in Toronto. Your apps, databases, and files live on that VM under Canadian jurisdiction. We handle the Coolify setup, security hardening, DNS, and SSL so you can focus on your product. We are not the whole solution. You still need to make thoughtful choices about every third-party service you use. See our [Canadian SaaS stack](/canadian-saas-stack) for a full breakdown of Canadian and non-US alternatives by category. But if you are building something that needs to credibly run on Canadian infrastructure, having a managed deployment platform that is already in the right jurisdiction is a solid starting point. The Starter and Pro plans include a 30-day free trial. Deploy a real project and see if it fits before committing. Our [getting started guide](/docs/deploy-your-first-app) walks through the full setup. {% cta-section title="Start building on Canadian infrastructure" %} MapleDeploy provisions a dedicated Coolify server in Toronto in minutes. Flat pricing starting at $45 CAD/month. No per-app fees, no shared infrastructure, and no US data exposure. {% /cta-section %} --- ## Canadian web hosting: what actually matters Most 'Canadian hosting' is just US companies with a Toronto data center. Here's how to evaluate providers when jurisdiction actually matters. URL: https://mapledeploy.ca/blog/canadian-web-hosting-what-matters Date: 2026-01-27 Search for "Canadian web hosting" and you'll find listicles ranking providers by price and uptime. Most are affiliate content, and most "Canadian" hosts they recommend are US companies with a Toronto data center. The distinction between "servers in Canada" and "Canadian hosting" is one that most of these articles never make. It matters more than you'd think. ## What "Canadian hosting" usually means Most providers advertising "Canadian servers" are offering exactly that: servers in Canada. The company is still American. Your data is still [subject to US law](/blog/us-cloud-act-canadian-businesses). This matters if you care about data sovereignty, whether for compliance or preference. GoDaddy is [headquartered in Tempe, Arizona](https://en.wikipedia.org/wiki/GoDaddy). Bluehost is owned by [Newfold Digital](https://www.newfold.com/), a US company formed in 2021 from the merger of Endurance International Group and Web.com, whose [portfolio of brands](https://en.wikipedia.org/wiki/Endurance_International_Group) includes HostGator, Network Solutions, Register.com, and many others. SiteGround is [a Bulgarian company](https://en.wikipedia.org/wiki/SiteGround) headquartered in Sofia. All three show up on "best Canadian hosting" lists, and all three will happily sell you a plan with a Canadian server location. None of them are Canadian businesses. There are genuinely Canadian providers. [Web Hosting Canada (WHC)](https://whc.ca/about-web-hosting-canada) is Montreal-based and has been since 2003. [HostPapa](https://www.hostpapa.com/about-hostpapa/contact/) is headquartered in Burlington, Ontario. These are real Canadian companies, but they mostly offer traditional shared hosting with cPanel. The point is that you need to check. A ".ca" domain and a maple leaf on the homepage don't tell you where the company is incorporated or whose law governs your data. For teams selling software or services to Canadian clients, Canadian jurisdiction is often a hard requirement. But you don't need a regulatory reason. "Fully Canadian" is becoming both a competitive advantage and a personal preference. ## From cPanel to containers Canadian web hosting used to mean one thing: shared hosting with cPanel. You'd get a login to a control panel, upload files via FTP, set up a MySQL database through phpMyAdmin, and configure email accounts. WHC, HostPapa, and dozens of smaller providers built their businesses on this model. It worked well for WordPress sites and PHP applications. The problem is that the rest of the hosting industry moved on. [Heroku](https://en.wikipedia.org/wiki/Heroku) popularized git push deployment in its early platform releases. Docker containers changed how applications are packaged. Vercel and Railway made deploying Node.js and Python applications trivial. These platforms offered a developer experience that cPanel shared hosting couldn't match. But all of these modern platforms are American. Heroku runs on AWS. Railway runs on US infrastructure. Vercel offers a Montreal function region, but Vercel is a US company, so the jurisdiction question is unchanged. Canadian developers who wanted a modern deployment experience had to leave Canadian infrastructure to get it. For years, the choice was between "Canadian jurisdiction with outdated tooling" and "modern developer experience on US infrastructure." That gap is what we built MapleDeploy to close. ## The latency question "Won't my site be slow for users outside Canada?" This is the first objection people raise, and in our experience the numbers don't support it. Typical round-trip latencies from Toronto run around 10ms to Montreal, roughly 15 to 25ms to New York and Chicago, 60 to 70ms to San Francisco, and under 90ms to London. Your own results will vary by network path and provider. For context, a typical database query takes tens of milliseconds and an API call to a third-party service often adds hundreds more. Network latency between Toronto and any major North American city is usually a rounding error in application response times. Your users will not notice the difference between a server in Toronto and a server in Virginia. If you're building a global consumer app optimized for users in Singapore or Sydney, use edge deployment. But for Canadian businesses serving North American users, and that covers most B2B SaaS, internal tools, client projects, and agency work, single-region Canadian hosting is the right call. ## PIPEDA and the federal baseline [PIPEDA](https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/) is Canada's federal privacy law. It requires organizations to protect personal information and be accountable for how it's handled. One detail that surprises people: PIPEDA does not explicitly require data to stay in Canada. You can transfer personal information outside Canada, provided you maintain [comparable protections](https://www.priv.gc.ca/en/privacy-topics/airports-and-borders/gl_dab_090127/) and your privacy policy discloses the transfer. That said, "comparable protections" is doing a lot of heavy lifting. If your hosting provider is a US company, your data is subject to the CLOUD Act regardless of where the servers physically sit. A US court can compel a US company to produce data stored anywhere in the world. Arguing that your CLOUD Act exposure constitutes "comparable protection" to keeping data under Canadian jurisdiction is a hard case to make, especially to a regulator reviewing your practices after an incident. In practice, keeping data on Canadian infrastructure under a Canadian-jurisdiction provider is the simplest way to meet PIPEDA's accountability requirements. No cross-border transfer disclosures, no adequacy assessments, no complicated contractual protections with foreign processors. It removes an entire category of compliance work. ## Provincial laws add more requirements PIPEDA sets the floor, not the ceiling. Several provinces have their own privacy legislation that goes further. Quebec's [Law 25](/blog/quebec-law-25-data-residency) is the most significant. Its final phase [took effect on September 22, 2024](https://www.canlii.org/en/qc/laws/stat/cqlr-c-p-39.1/latest/cqlr-c-p-39.1.html), completing a three-year rollout. It requires a privacy impact assessment before transferring personal information outside Quebec. If your application runs on US infrastructure, that counts as a cross-border transfer. The PIA must evaluate whether the destination jurisdiction provides adequate protection, and for US infrastructure subject to the CLOUD Act, that analysis is complex and the outcome is uncertain. Keeping data in Canada sidesteps this requirement entirely for your application data. Ontario's [Personal Health Information Protection Act (PHIPA)](https://www.ontario.ca/laws/statute/04p03) governs health data and restricts how personal health information can be disclosed outside Ontario. It binds health information custodians and the service providers that handle information on their behalf. Health workloads need a provider that will sign healthcare-specific terms. MapleDeploy does not, and our terms of service prohibit health and medical data. British Columbia's [PIPA](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/03063_01) applies broadly to private sector organizations operating in BC. It has no cross-border transfer rule. Section 34 requires organizations to make reasonable security arrangements for personal information in their custody or control, wherever it sits. BC's public sector rules changed in 2021. The Canada-only storage requirement in FIPPA section 30.1 was repealed effective November 25, 2021. Public bodies may now disclose personal information outside Canada under [section 33.1](https://www.bclaws.gov.bc.ca/civix/document/id/complete/statreg/96165_03), but only in accordance with regulations made by the responsible minister. Provincial rules are moving in different directions. Quebec has tightened cross-border requirements, while BC relaxed its public sector residency rule. Keeping data in Canada is the position that stays valid under either. ## What to look for Evaluating a hosting provider for Canadian data residency goes beyond checking a server location dropdown. Here's what actually matters. **Jurisdiction, not just geography.** Who owns the company? Where is it incorporated? A Canadian mailing address on the website doesn't mean much if the parent company is American. Check corporate registries, not marketing pages. If the provider uses AWS, GCP, or Azure under the hood, your data is with an American company regardless of the server location. **Compliance documentation.** Can they provide a data residency attestation? Do they have a published privacy policy that covers how they handle government data requests? If your workload needs specialized compliance terms, confirm the provider is prepared to accept them in writing. Providers who can't produce basic documentation probably haven't thought about it. **Developer experience.** This is where traditional Canadian hosts fall short. Can you deploy from a git repository? Do they support the languages and databases your application needs? Is there an API? If the developer experience feels like 2010, your team will fight it every day. **Pricing model.** Per-project or per-resource pricing adds up fast if you run multiple applications. Some providers charge separately for databases, SSL certificates, domains, and bandwidth. A flat monthly fee for a dedicated environment is simpler to budget and scales more predictably. **Backup and recovery policies.** Where are backups stored? Are they also in Canada? How quickly can you restore? Some providers store backups on US infrastructure even when the primary servers are Canadian, which creates a data residency gap that's easy to miss. **Infrastructure ownership.** Many providers [resell US cloud infrastructure](/blog/why-we-chose-canadian-first-infrastructure), meaning your data is still with an American company at the infrastructure layer. Ask whether they own or lease their servers, and from whom. "We use AWS Canada" is not the same as "We operate our own infrastructure in Canada." ## The modern option You no longer have to choose between "developer-friendly PaaS" and "Canadian jurisdiction." MapleDeploy is a [Canadian PaaS](/) alternative to the US platforms that dominate this space, and it gives you both: git push deployment, automatic SSL, one-click PostgreSQL, MySQL, Redis, and MongoDB. Actual [Canadian jurisdiction](/canadian-hosting), not just Canadian servers. See how we compare to [Heroku](/compare/heroku), [Railway](/compare/railway), [Vercel](/compare/vercel), [Render](/compare/render), [Fly.io](/compare/fly), and [DigitalOcean](/compare/digitalocean). Each customer gets a dedicated VM on Canadian-owned infrastructure in Toronto. No shared servers, no US cloud dependencies for your application data. The underlying infrastructure provider, [LunaNode](https://www.lunanode.com/about), is a BC-incorporated company operating its own hardware. That's Canadian jurisdiction at every layer. If jurisdiction doesn't matter to you, use whatever's cheapest. If you'd rather keep your projects on Canadian infrastructure, now you can without giving up the modern developer experience. Our [getting started guide](/docs/deploy-your-first-app) walks through the full setup from signup to a live app. {% cta-section title="Hosting that answers the question" %} Canadian jurisdiction, not just Canadian servers. Try MapleDeploy free for 30 days. {% /cta-section %} --- ## Coolify vs Dokploy: an honest comparison A side-by-side look at two popular self-hosted PaaS platforms. Maturity, service catalogs, multi-server support, and what each license allows. URL: https://mapledeploy.ca/blog/coolify-vs-dokploy Date: 2026-08-19 Two projects come up constantly in the self-hosted PaaS conversation: Coolify and Dokploy. Both install on a plain Linux server. Both give you git-based deploys, one-click services, managed databases, and a web UI. Both are free to run on hardware you control. They are closer on features than most comparison posts admit. The differences that actually matter are maturity, licensing, and how each project thinks about servers. Here is what we found, with sources, so you can decide on facts instead of impressions. ## What each one is **[Coolify](/open-source-stack)** was started in 2021 by Andras Bacsai and is [licensed under Apache 2.0](https://github.com/coollabsio/coolify/blob/main/LICENSE). The control plane is a Laravel and Livewire application that runs as a single PHP container. It manages servers over SSH, which means a VPS, bare metal, or a Raspberry Pi are all valid targets. **Dokploy** launched in June 2024, created by Mauricio Siu. It is written in TypeScript on Next.js and leans on Docker and Traefik for routing. It covers applications, databases, Docker Compose stacks, and [monitoring](https://docs.dokploy.com/docs/core/features) of CPU, memory, disk, and network usage. Self-hosted gets basic monitoring, and the advanced monitoring dashboard with configurable alert thresholds is a Dokploy Cloud feature on Startup and above. Both projects describe themselves as open-source alternatives to Heroku, Vercel, and Netlify. Both mean it. ## Maturity and community Coolify has roughly 60,000 GitHub stars. Dokploy has roughly 36,000. Star counts move constantly and every source reports them from a different snapshot, so treat both figures as ballpark and check the repos yourself. The interesting number is not the total, it is the rate. Dokploy covered that ground from a standing start in June 2024. That is real adoption, not hype. Coolify ships patch releases most weeks and feature releases every month or two, following a [documented branch and release-candidate workflow](https://github.com/coollabsio/coolify/blob/v4.x/RELEASE.md), with a nightly channel for people who want changes early. The current stable line is v4.3.x. Dokploy ships [frequent releases on GitHub](https://github.com/Dokploy/dokploy/releases) and development is visibly active. Where the age gap shows up in practice: when you hit an obscure problem at 11pm, Coolify's larger install base means someone has probably already posted about it. That is a support-surface advantage, not a code-quality one. ## Service catalogs Coolify ships [280+ one-click services](https://github.com/coollabsio/coolify). Dokploy's docs advertise [500+ open source templates](https://docs.dokploy.com/docs/templates), maintained as Docker Compose blueprints in a [dedicated repository](https://github.com/Dokploy/templates). Do not read too much into the raw numbers. The two projects count differently, and both catalogs are Docker Compose templates you can fork, edit, or write from scratch. What matters is whether the specific thing you want is in the list. Search both catalogs for your actual stack before you decide. ## Multi-server support This is where the two designs genuinely diverge. Coolify connects additional servers over SSH from one control panel, and you place resources on whichever server you want. Deploying the *same* application across multiple servers behind a load balancer is [documented as experimental](https://coolify.io/docs/knowledge-base/server/multiple-servers). Dokploy splits the problem in two. [Remote servers](https://docs.dokploy.com/docs/core/remote-servers) come in two flavours: deployment servers that run your apps, and build servers that only build images and push them to a registry. Each remote server runs its own Docker and its own Traefik and they deliberately do not form a cluster, so one server going down does not affect the others. Separately, Dokploy supports [Docker Swarm clustering](https://docs.dokploy.com/docs/core/cluster) if you do want to scale one application across nodes. Dokploy's Swarm support is a genuine differentiator. If multi-node orchestration is on your roadmap, that is a real reason to pick it. One caveat worth knowing up front: Dokploy build servers are [currently for applications only](https://docs.dokploy.com/docs/core/remote-servers/build-server) and do not support Docker Compose deployments. ## Docker Compose and build options Both platforms treat Docker Compose as a first-class input, not an afterthought. Coolify's [build packs](https://coolify.io/docs/applications/build-packs/overview) are Nixpacks, a static build pack, Dockerfile, and Docker Compose, with Railpack added as a further option in v4.1. You can also deploy a prebuilt image. Resources are organized as project, then environment, then resource, and each resource runs on a server you have connected. Dokploy supports Nixpacks, Railpack, Heroku buildpacks, Paketo buildpacks, Dockerfile, a static build type, and [native Docker Compose](https://docs.dokploy.com/docs/core/docker-compose). Databases overlap almost entirely. Both cover PostgreSQL, MySQL, MariaDB, MongoDB, and Redis. Coolify backs databases up to any S3-compatible storage. Dokploy does [scheduled database backups to S3](https://docs.dokploy.com/docs/core/databases/backups) and adds [volume backups](https://docs.dokploy.com/docs/core/volume-backups) for Docker named volumes, which is useful for apps that keep state outside a database. ## Interface and workflow Coolify organizes everything around servers and projects. Dokploy organizes around projects containing services, with remote servers as a separate section of the dashboard. Which one feels better is a personal call, and we are not going to pretend otherwise. Both install in minutes. Spin up a throwaway VPS, install each, deploy one real app, and delete the one you liked less. That hour will tell you more than any screenshot comparison. ## Licensing and what costs money This is the part worth reading carefully, because it is the clearest difference between the two. Coolify is Apache 2.0, end of story. [Coolify Cloud](https://coolify.io/pricing) runs the same open-source codebase, which means nothing is held back from the self-hosted version. Cloud is $5/month for up to two servers with $3/month per additional server, and it exists as a convenience, not as a feature gate. Dokploy is open core. Code outside the `/proprietary` directory is [Apache 2.0](https://github.com/Dokploy/dokploy/blob/canary/LICENSE.MD); code inside that directory falls under the separate Dokploy Source Available License, which allows you to read and contribute to the code but requires a paid license to run it in production. [Enterprise features](https://docs.dokploy.com/docs/core/enterprise) need a license key: SSO, SCIM provisioning, custom roles, audit logs, application authentication, and whitelabeling. Concurrent builds are open source and configurable per server, from 1 to 100, and are a self-hosted feature rather than a Cloud one. [Dokploy Cloud](https://dokploy.com/pricing) starts at $4.50/month per server on Hobby, with Startup from $15/month for three servers. One detail worth correcting, because older comparisons still repeat it: Dokploy's earlier license was an adapted Apache 2.0 that placed extra restrictions on multi-node support, Docker Compose support, schedules, and preview deployments. Those clauses are gone. Dokploy [moved the core to standard Apache 2.0 in January 2026](https://github.com/Dokploy/dokploy/blob/canary/LICENSE.MD), so multi-node and Docker Compose are plain Apache 2.0 in the self-hosted version. In the [announcement](https://dokploy.com/blog/we-are-updating-dokploys-open-source-license), the project also committed to never moving functionality from the open-source license to the paid one. For a solo developer or a small team running their own apps, none of this changes anything. Both are free and both will do the job. It matters if you need one of the enterprise features. One caveat on all of this. We are describing what the license texts say, not advising you on how they apply to your business. Both documents are short and linked above. Read them yourself if the details matter to what you are building. ## Side by side | | Coolify | Dokploy | |---|---|---| | **First release** | 2021 | 2024 | | **Built with** | Laravel, Livewire (PHP) | Next.js, TypeScript | | **License** | Apache 2.0 | Apache 2.0 core, `/proprietary` directory under the Dokploy Source Available License | | **GitHub stars** | ~60,000 | ~36,000 | | **Release channels** | Stable every 2-4 weeks, plus nightly | Releases published on GitHub | | **One-click catalog** | 280+ services | 500+ templates | | **Build options** | Nixpacks, Railpack, static, Dockerfile, Compose, prebuilt image | Nixpacks, Railpack, Heroku and Paketo buildpacks, Dockerfile, static, Compose | | **Reverse proxy** | Traefik (default), Caddy (experimental), custom | Traefik | | **Multi-server** | Servers over SSH; same-app multi-server is experimental | Deployment and build servers, plus Docker Swarm clustering | | **Backups** | Databases to S3-compatible storage | Databases to S3, plus volume backups | | **Paywalled in self-hosted** | Nothing | SSO, SCIM, custom roles, audit logs, whitelabeling | | **Managed option** | Coolify Cloud from $5/mo | Dokploy Cloud from $4.50/mo per server | ## Which one fits you **Pick Dokploy if** you want Docker Swarm clustering, you like the separation between build servers and deployment servers, or you simply prefer working in a TypeScript codebase you might contribute to. Volume backups are a nice touch if your apps store state outside a database. Just confirm that nothing you need sits behind the enterprise license. **Pick Coolify if** you want the larger community, a bigger body of answers to the problems you will actually hit, and a license with no asterisks. Because Coolify Cloud runs the same codebase as the self-hosted build, the question "is this feature behind a paid tier" never comes up. Neither answer is wrong. Both are actively maintained projects with real users running real production workloads. ## If you land on Coolify but don't want to operate it Self-hosting means you own the updates, the security patches, the backups, and the 2am recovery. That is a fair trade for a lot of developers. For others it is the reason the project never leaves the "someday" list. MapleDeploy runs managed Coolify on [Canadian infrastructure](/canadian-hosting), specifically LunaNode in Toronto. Each customer gets a dedicated VM with their own Coolify instance. Plans are flat CAD per month, starting at $45 for 4 GB RAM and 2 vCPUs, with a 30-day free trial on the Starter and Pro tiers. It is the same open-source Coolify, so nothing about it locks you in. If you want to see what deploying on Coolify actually looks like first, our [step-by-step deployment guide](/blog/deploy-app-coolify-guide) walks through a real project. {% cta-section title="Try managed Coolify" %} 30 days free on Starter and Pro. Canadian infrastructure, flat CAD pricing. {% /cta-section %} --- ## Coolify vs Heroku vs Railway compared Comparing three deployment platforms from a Canadian perspective. Features, pricing, data residency, and which one fits your project. URL: https://mapledeploy.ca/blog/coolify-vs-heroku-vs-railway Date: 2026-05-05 Four platforms, four different tradeoffs. Heroku is the established player. Railway is the modern alternative. Coolify is the open-source, self-hosted option. MapleDeploy is managed Coolify on Canadian infrastructure. This post walks through each one honestly so you can make the right call for your project. ## Heroku Heroku pioneered the git-push deployment model and remains one of the most mature platforms available. `git push heroku main` and your app is deployed. The add-on marketplace covers most common needs: databases, caching, monitoring, email. Documentation is thorough and the ecosystem has been battle-tested for over 15 years. [Pricing](https://devcenter.heroku.com/articles/dyno-types) starts at $5/month for an Eco dyno or $7/month for Basic, and $25-50/month for Standard dynos. [PostgreSQL](https://elements.heroku.com/addons/heroku-postgresql) runs from $5/month for the Essential tier and jumps to $50/month for Standard. Add-ons compound quickly. A realistic production setup with a database, logging, and a worker dyno can easily reach $100-200/month before you account for traffic. [The free tier was removed in 2022](https://www.heroku.com/blog/next-chapter), which forced a lot of small projects to migrate and exposed how expensive Heroku gets at scale. The harder limitation for Canadian teams: Heroku is owned by Salesforce, a US company, and runs on AWS. The common runtime offers US and EU regions only. [Private Spaces does include Montreal](https://devcenter.heroku.com/articles/regions), but at significantly higher cost. And regardless of region, Heroku is a US company [subject to the CLOUD Act](/blog/us-cloud-act-canadian-businesses). See our [full Heroku comparison](/compare/heroku) for a side-by-side breakdown. ## Railway Railway has the best developer experience of any platform on this list. Connect a repo, configure a few environment variables, and you have a deployed service with a managed database, real-time logs, and automatic SSL. The UI is genuinely good. Team collaboration works as expected. [Pricing](https://railway.com/pricing) is usage-based on the Pro plan: $20 USD/month (includes $20 in usage credits), with compute billed at approximately $20/vCPU/month and $10/GB RAM/month, and egress at $0.05/GB. The Hobby plan is $5/month with $5 in usage credits included, and a permanent Free plan at $0/month includes $1 in monthly credits, limited to 1 vCPU and 0.5 GB RAM per service. There is also a [free trial with $5 in credits that expire in 30 days](https://docs.railway.com/pricing/free-trial). Usage-based pricing is transparent in principle, but harder to budget for than a flat rate. A moderate backend service with a database and regular traffic can run $40-80 USD/month once you add it up. Railway is a San Francisco company running on their own bare metal infrastructure with [regions in the US, EU (Amsterdam), and Southeast Asia (Singapore)](https://docs.railway.com/deployments/regions). There is no Canadian region option, and the same [jurisdiction concerns](/blog/us-cloud-act-canadian-businesses) that apply to Heroku apply here. See our [full Railway comparison](/compare/railway) for details. ## Coolify (self-hosted) **[Coolify](/open-source-stack)** is an [open-source (Apache 2.0)](https://github.com/coollabsio/coolify/blob/main/LICENSE) platform you deploy on your own server. You get git-based deploys, one-click databases (PostgreSQL, MySQL, Redis, MongoDB), Docker and Docker Compose support, real-time logs, and a capable web UI. The underlying experience is solid and improving quickly. The cost is your server, not the software. A $20-40/month VPS from any provider covers most small-to-medium workloads. The tradeoff is operational responsibility. You manage updates, security patches, backups, and monitoring. If the Coolify process crashes or a Docker network gets into a bad state at 2am, that's your problem. For developers comfortable with Linux and Docker, this is manageable. For teams without a dedicated DevOps person, the operational overhead adds up. Self-hosted Coolify is genuinely compelling for developers who want full control and have the skills to run it. You choose the infrastructure, which means you can choose a Canadian server and get [Canadian data residency](/canadian-hosting) by default. ## MapleDeploy **MapleDeploy** is managed Coolify running on LunaNode infrastructure in Toronto: a [Canadian platform as a service](/git-push-deploys). You get the same Coolify experience (git-based deploys, one-click databases, Docker support, real-time logs) without managing the underlying platform. **Pricing** is flat CAD per month, all-inclusive: | Plan | RAM | vCPUs | Storage | Price | |------|-----|-------|---------|-------| | Starter | 4 GB | 2 | 35 GB | $45 CAD/mo | | Pro | 8 GB | 4 | 70 GB | $95 CAD/mo | | Ultra | 16 GB | 6 | 125 GB | $195 CAD/mo | | Ultra 32 | 32 GB | 8 | 250 GB | $395 CAD/mo | | Ultra 64 | 64 GB | 8 | 500 GB | $695 CAD/mo | Each customer gets a dedicated VM. No shared compute, no noisy neighbors. Within your plan's resources, you can run as many applications and databases as you want with no per-project fees. Starter and Pro plans include a 30-day free trial. See the [getting started guide](/docs/deploy-your-first-app) for the full setup walkthrough. The platform is [Canadian-owned and operated](/canadian-hosting), running on LunaNode infrastructure in Toronto. No US parent company, no CLOUD Act exposure. MapleDeploy runs in one region, Toronto, and that is deliberate. Keeping every customer workload on Canadian infrastructure under Canadian jurisdiction only works if we stay in Canada. For global audiences, a CDN like Bunny.net or Cloudflare in front of your VM handles edge caching while your origin and data stay in Canada. ## Platform comparison | | Heroku | Railway | Coolify (self-hosted) | MapleDeploy | |---|---|---|---|---| | **Pricing model** | Per dyno + add-ons | Per workspace + usage | Server cost only | Flat CAD/mo | | **Infrastructure** | AWS (US/EU) | Bare metal (US/EU/Asia) | Your choice | LunaNode (Toronto) | | **Jurisdiction** | US (Salesforce) | US (San Francisco) | Depends on provider | Canada | | **CLOUD Act exposure** | Yes | Yes | Depends on provider | No | | **Managed service** | Yes | Yes | No (you manage it) | Yes | | **Dedicated VM** | Performance dynos and Private Spaces only | Enterprise plan only | Yes (your server) | Yes (every plan) | | **Databases** | Add-on marketplace | Built-in, usage-billed | One-click, self-hosted | One-click, included | | **Deploy method** | Git push, CLI | Git repo connect | Git push, Docker | Git push, Docker | | **Vendor lock-in** | High (Heroku-specific) | Medium | None (open source) | Low (Coolify is open source) | | **Free tier** | No (removed 2022) | Trial ($5 one-time credit); Free plan ($1/mo credit) | Yes (self-hosted) | 30-day trial (Starter/Pro) | ## Which platform to choose **Use Heroku if** you need a mature ecosystem with a large add-on marketplace, your team is already familiar with it, and US data residency is not a concern. It is the safest default for non-Canadian projects that want a proven platform. **Use Railway if** developer experience is the top priority and your team values a modern, well-designed UI. It is genuinely excellent for teams that want fast iteration and don't have compliance requirements. Expect variable monthly costs. **Use Coolify (self-hosted) if** you want full control, have the DevOps capacity to run it, and want zero platform fees. Pair it with a Canadian VPS provider like LunaNode and you have Canadian data residency with complete ownership of the stack. The best option for technically capable teams on a tight budget. **Use MapleDeploy if** you want the Coolify experience without the operational overhead, and Canadian data residency is a requirement or a preference. Flat CAD pricing makes it easy to budget. Each customer gets a dedicated VM, so resource contention is not a factor. The 30-day trial on Starter and Pro lets you run a real project before committing. ## The Canadian angle For many projects, jurisdiction doesn't factor into the decision. A marketing site, an internal tool, a weekend experiment: any of these platforms works fine. But some developers and teams care about where their infrastructure lives. Maybe it's a compliance requirement. Maybe enterprise clients ask "where does our data live?" and you need a clear answer. Or maybe you just prefer Canadian infrastructure on principle. The [CLOUD Act makes this a jurisdiction decision, not just a geography decision](/blog/us-cloud-act-canadian-businesses). If that matters to your project, the only options on this list that address it cleanly are self-hosted Coolify on a Canadian server and MapleDeploy. The difference between them is who manages the infrastructure. MapleDeploy plans start at $45 CAD/month with a 30-day free trial. {% cta-section title="Get started" %} Try MapleDeploy free for 30 days. See how it compares for yourself. {% /cta-section %} --- ## Proof of Canadian data residency: what to ask for A client wants proof your data stays in Canada. The documentation to request from your hosting provider, and why a Toronto location alone is not an answer. URL: https://mapledeploy.ca/blog/data-residency-documentation-checklist Date: 2026-09-05 A client asks you to prove their data stays in Canada. You're not the one buying hosting here, you're the vendor answering to your own client's procurement or security review, and you need your hosting provider to hand you something more useful than a marketing page. "Proof" means specific documents: a named legal entity, a physical data center location, a subprocessor list, and a written answer on what happens to backups, logs, and support access. A region selector that says "Toronto" is not proof of anything by itself. It tells you nothing about who owns the company running that server or whether your data ever leaves that jurisdiction through a backup job, a support ticket, or a foreign parent company. ## Why "hosted in Canada" isn't the same as "proof" Plenty of hosting providers let you pick a Canadian region while the company itself, and often its backups, logs, and support staff, sit somewhere else entirely. A region label is a setting. It can be changed, it can have exceptions you were never told about, and it says nothing about corporate jurisdiction. Your client isn't asking where a server happens to sit today. They're asking what governs that data, and who can be compelled to hand it over. Getting real proof means asking for documents, not a checkbox. ## The documentation checklist Ask your hosting provider for each of the following, in this order. Each one closes a specific gap the previous one leaves open. 1. **The legal entity, and where it's incorporated.** The registered company name and its jurisdiction, not a brand name. A `.ca` domain and a Canadian mailing address prove nothing about who owns the business. 2. **The physical data center location, and who operates it.** Which city, and which company runs the hardware. "AWS Canada" and "a Canadian company that owns its hardware in Toronto" are different chains of legal exposure. 3. **The subprocessor list, and where each one sits.** Email delivery, DNS, monitoring, payments. Your primary data can be Canadian while three or four ancillary services quietly are not. 4. **Whether a foreign parent brings the US CLOUD Act into scope.** A Canadian subsidiary of a US parent is generally still within reach of US legal process, because the parent can be compelled to produce data in its possession, custody, or control. 5. **Backup and log locations.** The gap almost everyone misses. A provider can truthfully say your primary data is Canadian while your database backups sit with another company in another country. 6. **Support-access locations.** A Canadian data center means little if a support team on another continent can remote into it to fix things. 7. **What happens on termination.** Whether there's a retention window, whether deletion is actually permanent, and whether you can export everything before you leave. Most providers can answer item 2 without blinking. Fewer can produce a clean answer to item 3. By item 5, plenty of providers go quiet, because nobody has ever asked them to document where the backups actually go. That gap between a marketing claim and a written answer is exactly what your client is trying to find out before it's their problem. ## What about SOC 2 and ISO 27001? You'll see these mentioned constantly in generic advice about data residency documentation, so it's worth being precise about what they actually tell you. A SOC 2 report or an ISO 27001 certification is evidence of a security controls program: access management, change control, incident response, that kind of thing. Some SOC 2 reports do state the specific facilities in scope, which can be useful. Neither certification is, by itself, an answer to "where does my data live and whose law governs it." A US company with servers in Virginia can hold both. Ask for them if your client's review requires them, but don't accept either one as a substitute for the seven items above. They answer a different question. ## What MapleDeploy publishes against this checklist We built this list because it's the same one we'd want handed to us if we were the client. Here's where each item lives for MapleDeploy. | Checklist item | Our answer | Document | |---|---|---| | Legal entity and jurisdiction | Lawrence Digital, registered in Ontario, Canada. Formal verification available on request. | [Canadian ownership verification](/legal/canadian-ownership) | | Data center location and operator | Toronto, on infrastructure operated by LunaNode Hosting Inc., a Canadian corporation incorporated in British Columbia. | [Data residency attestation](/legal/data-residency) | | Subprocessor list | Every sub-processor that touches customer or account data, named, with its country. | [Sub-processors](/legal/subprocessors) | | Foreign parent, CLOUD Act exposure | No US parent at either the MapleDeploy or LunaNode level. Three ancillary services have US ties and are disclosed individually with the data each one handles. | [Sub-processors](/legal/subprocessors) | | Backup and log locations | Server snapshots stay on the same Toronto infrastructure as your server. Database backups go wherever you point Coolify's S3 backup, and we document a Canadian option. Logs are encrypted on Canadian infrastructure. | [Backup guide](/docs/backups) | | Support-access locations | All support and administrative access happens from Toronto. No offshore support desk, no third-party support contractor. | Stated here | | What happens on termination | Cancellation starts a 7-day grace period with the server powered off, revertible from the dashboard. Then a final snapshot is taken, the VM is deleted, and that snapshot is kept 30 days and restorable on request. | [Data residency attestation](/legal/data-residency) | If your client's review needs something these pages don't cover, [email us](mailto:hello@mapledeploy.ca) and we'll answer directly rather than pointing you back at a marketing claim. None of this replaces [reading the full legal documentation](/legal) yourself, or getting advice from your own counsel on what your specific client relationship requires. If the CLOUD Act itself is the part you need to explain to your client, we've written that up separately with the underlying legal mechanics: [the US CLOUD Act, explained for Canadian businesses](/blog/us-cloud-act-canadian-businesses). For the broader case for [Canadian data sovereignty](/canadian-hosting), including how it interacts with PIPEDA and Quebec's Law 25, that page covers the ground this post doesn't. {% cta-section title="Try Canadian infrastructure" %} 30 days free on Starter and Pro. Your code and your data, on Canadian soil. {% /cta-section %} --- ## Data residency vs data sovereignty: the difference Residency is where your data sits. Sovereignty is whose law can compel access to it. The difference, what localization adds, and how to evaluate a host. URL: https://mapledeploy.ca/blog/data-residency-vs-data-sovereignty Date: 2026-09-08 **Data residency** is about geography: which country or region physically holds your data. **Data sovereignty** is about law: which government can compel access to that data, no matter where it sits. The two usually overlap. They don't have to, and the gap between them is the whole reason this distinction matters when you're picking a cloud host. Here's the sharpest example. A US-owned provider that opens a Toronto region gives you Canadian data residency. It does not give you Canadian data sovereignty, because the company itself is still American, and the **US CLOUD Act** lets US courts compel American companies to produce data they control, regardless of which country it's stored in. Residency describes the server. Sovereignty describes the law that can reach the company running it. ## Data residency: where the bytes sit Residency is the simplest of the three terms. It answers one question: in which physical location is your data stored and processed? Residency is usually a matter of choice, not law. When you provision a database or pick a hosting region, you're making a residency decision. It's often driven by latency, a contractual promise to a client, or a general compliance policy that says "keep customer data in Canada." Picking a region is straightforward. It's also, by itself, an incomplete answer to "where is my data really governed." ## Data sovereignty: whose law reaches the data Sovereignty goes further than location. It asks which country's courts, regulators, and law enforcement can compel the company holding your data to hand it over, or to explain, disable, or modify it. That depends on corporate structure more than server location: who owns the company, where it's incorporated, and which laws its parent entity answers to. This is why sovereignty is the harder property to verify. Two providers can offer identical-looking Canadian regions and sit in completely different legal positions. The CLOUD Act is the clearest working example. In 2018, the United States passed the Clarifying Lawful Overseas Use of Data Act. It gives US law enforcement a way to compel companies subject to US jurisdiction, typically US-incorporated companies, to produce data they control, wherever in the world that data happens to be stored. A Toronto data center doesn't change who the order is served on. It's served on the company, and the company answers to US courts regardless of where its servers sit. That doesn't make every request blanket surveillance. Content data generally requires stronger legal process than basic subscriber information, and providers can contest orders on comity grounds. The CLOUD Act's own motion-to-quash route is narrower than it sounds, though: it applies only where the subscriber is not a US person and disclosure would break the law of a qualifying foreign government, meaning one that has a CLOUD Act executive agreement in force. Canada does not have one. Negotiations were announced in March 2022 and have not concluded. But challenging a government order is expensive, slow, and uncertain, and no jurisdiction offers a perfect shield: Canada and the US cooperate through treaties and judicial assistance too. What changes with ownership and incorporation is which legal process governs the request in the first place, a Canadian court process versus a US order sent directly to a US company. For the full mechanics, see our breakdown of [the CLOUD Act and what it means for Canadian businesses](/blog/us-cloud-act-canadian-businesses). ## Data localization: the third term, and the one Canada doesn't impose on commercial hosting Most comparisons stop at two terms and miss a third one worth knowing: **data localization**, a legal requirement that certain data must be stored and processed inside a specific country's borders, full stop. Localization isn't a choice you make when provisioning infrastructure. It's a law that removes the choice. Residency, sovereignty, and localization answer three different questions. Residency is where you chose to put the data. Sovereignty is which country's law can reach the company holding it. Localization is whether the law forces the choice on you at all. Here's the honest concession, because it's the part that makes the rest of this credible: Canada has no general commercial data localization law. PIPEDA, the federal private-sector privacy law, doesn't require personal information to physically stay within Canadian borders. The Office of the Privacy Commissioner is explicit about it, in guidance it issued in 2009 and reaffirmed after a 2019 consultation on transborder dataflows: [PIPEDA does not prohibit organizations in Canada from transferring personal information to an organization in another jurisdiction for processing](https://www.priv.gc.ca/en/privacy-topics/airports-and-borders/gl_dab_090127/). What it requires instead is that you stay accountable for the data and use contractual or other means to provide a comparable level of protection wherever it goes. That same guidance makes the sovereignty point better than we can. No contract, it notes, can override the criminal, national security, or other laws of the country the information was transferred to. Comparable protection is a promise between two companies. It is not a shield against a government. Quebec's Law 25 comes closest, and even that isn't a localization mandate. It requires a privacy impact assessment before transferring personal information outside Quebec, and the transfer may proceed only if that assessment establishes the information would receive adequate protection. Contractual and technical mitigation measures feed into that assessment and have to be captured in a written agreement. That is a conditional gate rather than a flat ban on foreign hosting, but it is more than paperwork. See our full breakdown of [Quebec's Law 25 and what it requires](/blog/quebec-law-25-data-residency). So if you're choosing [Canadian infrastructure](/canadian-hosting), you're doing it because you decided jurisdiction matters, not because Canadian law is forcing your hand. That's a weaker legal argument and a more honest one. ## The three terms, side by side | Term | Core question | What determines it | Example | | --- | --- | --- | --- | | Data residency | Where does the data physically sit? | Your choice at provisioning, or a contractual commitment | Selecting a Toronto region for your database | | Data sovereignty | Which country's laws can compel access to the data? | Who owns and incorporates the company handling it | A US-owned provider stays reachable by the CLOUD Act even when it runs a Canadian region | | Data localization | Does the law require the data to stay in-country? | Legislation, not choice | Some jurisdictions mandate it outright; Canada has no general commercial localization requirement | ## How to evaluate a provider A region label on a pricing page tells you almost nothing about sovereignty. Ask the questions that actually resolve it. ### A practical test for any cloud host Work through these before you trust a region label. - Who owns the company, and in which country is it incorporated? - Which country's courts and regulators can issue an order the company has to obey? - Where does the primary application data physically sit, not just where the marketing page says? - Where do backups and disaster-recovery copies sit? This is the detail most residency claims quietly skip. - Who can access the system for support and administration, and from where? None of these questions has a universally correct answer. What matters is that you get a real answer to each one, instead of a region label standing in for all five. ## Where MapleDeploy fits MapleDeploy is Canadian-owned and operated, running managed Coolify on dedicated VMs at LunaNode in Toronto. For our customers, residency and sovereignty point the same direction: your application data sits in Canada, and the company running the infrastructure is Canadian, not a US entity with a Canadian region bolted on. We're transparent about the one place we don't control the full stack. Payment processing runs through Stripe, a US company, for PCI compliance reasons, and we offer Interac e-Transfer as a Canadian alternative. See [why we use Stripe](/blog/why-we-use-stripe) for that tradeoff in full. {% cta-section title="Residency and sovereignty, in the same place" %} Canadian infrastructure, Canadian ownership. Try Starter or Pro free for 30 days. {% /cta-section %} --- ## From code to production in 10 minutes with Coolify Deploy a web app on Coolify in 10 minutes. Covers Dockerfile vs Nixpacks, port configuration, and custom domain setup with SSL. URL: https://mapledeploy.ca/blog/deploy-app-coolify-guide Date: 2026-04-15 You have a working application on your machine. A Next.js frontend, a Python API, a Go service. It runs locally. Now you need it on the internet, with a real URL, SSL, and a deployment workflow that doesn't require a systems engineering degree. [Coolify](https://coolify.io) is an [open-source deployment platform](/open-source-stack) that handles the build, deploy, and hosting pipeline. Think of it as a self-hosted alternative to Heroku or Railway. Connect a Git repo, configure the build, and deploy. Here's the full workflow. ## Step 1: Connect your repository If you're using **GitHub**, go to Sources in the sidebar and add a new GitHub App. Authorize it, select which repositories to share, and you're connected. This is a one-time setup. Every future project can use the same source, and Coolify automatically configures webhooks for push-triggered deployments. For **GitLab, Bitbucket, Gitea**, or other providers, you'll use deploy keys instead. When you add your application in Step 2, choose "Private Repository (Deploy Key)" and provide the SSH URL. Coolify generates a key pair. Add the public key to your provider's repository settings, and optionally configure a webhook for auto-deploy on push. {% content-image src="coolify-sources-zoom-content" caption="The Sources page after connecting a GitHub App. One-time setup, then every project can use it." width=407 height=128 /%} ## Step 2: Create a project and application Go to Projects, create a new one, then add a new resource. Select your repository and branch. Coolify will ask how you want to build it. {% content-image src="coolify-add-resource-zoom-types" caption="Choose between public and private repository options when adding a new resource." width=1664 height=598 /%} ## Step 3: Pick your build method Coolify offers four build packs: **Nixpacks**, **Static**, **Dockerfile**, and **Docker Compose**. For a static site, pick Static. For a multi-service app with an existing compose file, pick Docker Compose. For everything else, the choice is between **Dockerfile** and **Nixpacks**. **Dockerfile** is the reliable choice. You control the build, the dependencies, the runtime. If your repo already has a Dockerfile, select it and you're done. **Nixpacks** auto-detects your language and framework. It works well for standard Node.js, Python, Go, and Ruby projects. For anything with a custom build process or a monorepo, Dockerfile is more predictable. Either way, set the **"Ports Exposes"** field to match the port your application listens on. A Next.js app uses 3000. A Flask app uses 5000. If this doesn't match, the deploy will succeed but the app won't respond. {% content-image src="coolify-app-config-zoom-network" caption="Set Ports Exposes to match the port your application listens on." width=1664 height=224 /%} ## Step 4: Deploy and test Hit deploy. Coolify pulls your code, builds the image, and starts the container. You can watch the logs in real time. {% content-image src="coolify-deploy-log-zoom-log" caption="Timestamped logs show exactly what's happening at each step of the build and deployment." width=1664 height=865 /%} Once it finishes, check the temporary URL under the "Links" dropdown at the top of the application page. If you see your app, it's working. If you see a 502, double-check the port configuration. {% content-image src="coolify-links-temp-zoom-panel" caption="The Links dropdown shows your app's temporary URL. No DNS needed yet." width=612 height=171 /%} At this point, your app is live. No domain setup required, no DNS, no certificates. Just a working URL you can share or test against. ## Step 5: Add a custom domain When you're ready for a real URL, two things need to happen. First, point your domain's DNS at your server. Create an A record with your server's IP address. If you're on MapleDeploy, you can find this in your dashboard or in Coolify under server settings. Second, set the "Domains" field in your Coolify application to your full domain(s): ``` https://example.com,https://www.example.com ``` {% content-image src="coolify-app-config-zoom-general-config" caption="Enter your custom domains in the Domains field using the full URL format." width=1664 height=518 /%} Redeploy, and Coolify will automatically provision an SSL certificate via Let's Encrypt. Give DNS a few minutes to propagate, and your app is live on your own domain with HTTPS. ## Common gotchas **Port mismatch** is the most frequent issue. Your app listens on 8080, Coolify expects 3000. The deploy looks successful but nothing loads. Always verify "Ports Exposes" matches your app's actual port. **Binding to localhost** breaks containerized apps. Your application needs to bind to `0.0.0.0`, not `127.0.0.1`. This is a Docker networking fundamental, but it catches people who haven't containerized before. **Build-time vs. runtime environment variables.** By default, Coolify injects environment variables at runtime. If your framework needs them at build time (like `NEXT_PUBLIC_` variables in Next.js), toggle "Available at Buildtime" on for those specific variables. **Nixpacks detection failures.** If Nixpacks can't figure out your project, switch to a Dockerfile. You can generate a starting point by running `nixpacks build . --out .` locally, which saves the generated Dockerfile to your project directory. Adjust it to fit your needs. ## Why Dockerfile over Nixpacks? Nixpacks is convenient. For a standard single-framework project with a clear `package.json` or `requirements.txt`, it just works. But convenience has limits. Dockerfiles are explicit. You control the base image, the build steps, the runtime. When something breaks, the Dockerfile tells you exactly what happened. With Nixpacks, you're debugging an auto-generated build plan you didn't write. For production workloads, Dockerfile wins on predictability. For quick prototypes, Nixpacks saves time. Use whichever matches the situation. ## Where MapleDeploy fits Coolify is open source. You can install it on any VPS and manage everything yourself. Or you can skip the server administration entirely. MapleDeploy gives you a fully managed Coolify instance on [Canadian infrastructure](/canadian-hosting) in Toronto. We handle the VM, OS updates, security patches, and monitoring. You get the deployment platform without the ops work. Each server is a dedicated VM. No shared infrastructure, no noisy neighbors. Plans start at $45 CAD/month with a 30-day free trial. Connect your repo and deploy. For the full step-by-step guide including server provisioning and troubleshooting, see our [getting started](/docs/deploy-your-first-app) documentation. {% cta-section title="Deploy your first app" %} 30-day free trial. Push your repo, get a live URL. Plans start at $45 CAD/month. {% /cta-section %} --- ## You built it with AI. Now what? AI tools are incredible for writing code. But deploying to production still means servers, SSL, DNS, and databases. Here's how to close the gap. URL: https://mapledeploy.ca/blog/deploy-your-ai-built-project Date: 2026-04-14 AI coding tools have changed what one person can build in a weekend. [Claude Code](https://www.anthropic.com/claude-code), [Cursor](https://cursor.com), [GitHub Copilot](https://github.com/features/copilot), [Windsurf](https://windsurf.com), [Bolt](https://bolt.new), [Lovable](https://lovable.dev), [v0](https://v0.app), [Replit Agent](https://replit.com). The list keeps growing. A solo developer can now produce a full-stack app, an API, and a SaaS prototype in the time it used to take to scaffold one project. The output is real code, too. Not toy demos. In our experience, Claude Code can generate complete Nest.js backends with authentication middleware, and Cursor can scaffold Next.js apps with Tailwind, database schemas, and API routes. Bolt and Lovable produce full-stack React applications with working backends. v0 generates UI components ready to drop into a Next.js project. Replit Agent builds applications with databases and authentication, then hosts them on Replit's infrastructure. Windsurf takes a similar approach to Cursor with its own take on context-aware code generation. These tools output standard project files: package.json, requirements.txt, and in the case of the coding agents, Dockerfiles and docker-compose configurations. The code is production-shaped from the start. This changes the deployment math. Not because deployment got harder, but because the ratio shifted. When writing code was the bottleneck, you deployed one or two things a month. When AI removes that bottleneck, you might have five projects in a weekend that are worth putting in front of users. The infrastructure model you choose needs to account for that. ## Per-project billing doesn't scale with prototyping speed Most deployment platforms charge per application, per database, per service. Railway meters CPU, RAM, and egress. Heroku bills per dyno plus add-ons. [Render](/compare/render) charges per service instance. This is fine when you deploy one thing and iterate on it. It breaks down when AI lets you build faster than you can evaluate. You spin up a prototype, add a database, expose an API. Then you build something else. And something else. Each one is small, but the per-project costs compound. A $10 database here, a $7 service there. Suddenly you're paying $80/month across four experiments, most of which you'll abandon within two weeks. Here's a concrete example. Say you build three small projects in a weekend with Cursor: a Next.js SaaS app, a Flask API, and a Discord bot with a database. On [Railway](https://railway.com/pricing), you pay per resource: roughly [$20 USD per vCPU per month, $10 per GB of RAM, and $0.15 per GB of storage per month](https://railway.com/pricing). The Hobby plan is $5 USD/month with $5 of usage included, enough for one small service. A modest service and its Postgres database might run $15-30 USD/month combined, depending on actual usage. Three projects with databases could land in the $40-70 USD/month range, which pushes you onto the Pro plan ($20 USD/month, including $20 of usage). On [Render](https://render.com/pricing), three web services at $7 USD each plus three Basic Postgres databases at $6 USD each puts you at $39 USD/month minimum. That's before you hit the resource limits that force an upgrade. On [Heroku](https://www.heroku.com/pricing), three Basic dynos at $7 USD each plus three Essential Postgres instances at $5 USD each is $36 USD/month at the low end. Realistic production setups climb fast once you add logging and worker dynos. The billing model was designed for a world where building was slow and deliberate. AI-assisted development isn't that. ## The last mile that AI doesn't cover AI tools are excellent at generating application code. They're less helpful with the infrastructure around it. This is the gap that catches most people after the initial excitement of a working prototype. DNS configuration is the first wall. Your app runs on localhost. Now you need it at a real domain. That means buying a domain, pointing DNS records, waiting for propagation, and debugging when the records don't resolve. Some agents can drive a DNS provider's API for you, but you still own the domain, the records, and whatever breaks. SSL certificates come next. Browsers reject HTTP connections. You need HTTPS, which means provisioning and renewing TLS certificates. Let's Encrypt made this free, but the automation around certificate renewal still requires infrastructure. Environment variables are another common stumbling block. Your AI-generated app has a `.env.example` with `DATABASE_URL`, `STRIPE_SECRET_KEY`, and `JWT_SECRET`. Locally, those are filled in. In production, you need a secure way to inject them into the runtime without committing secrets to your repo. Database provisioning trips people up too. Your app expects PostgreSQL. Where does that database run? How do you create it, set credentials, run migrations, and handle backups? AI generated the schema and migration files. It didn't provision the actual database server. Then there's the question of persistent storage, logging, and health checks. Production applications need all three. Setting them up from scratch on a bare VPS takes hours of configuration that has nothing to do with the code AI helped you write. A managed platform handles all of this. MapleDeploy gives you automatic SSL on every deployment, one-click database provisioning, environment variable management through the Coolify UI, and custom domain configuration with clear DNS instructions. The gap between "it works on my machine" and "it's live on the internet" is exactly what the platform covers. ## Resource-based beats project-based The alternative is to pay for resources, not projects. Get a server with defined CPU, RAM, and storage. Deploy as many applications and databases as fit. The cost doesn't change whether you're running one project or ten. This is what MapleDeploy does. You get a dedicated VM starting at $45 CAD/month with 4 GB RAM, 2 vCPUs, and 35 GB storage. Within that, deploy whatever you want: a Next.js frontend, a Flask API, a PostgreSQL database, a Redis cache. No per-project fees, no usage metering. The price is the same at the end of the month regardless of how many experiments you ran. Those three projects from the earlier example? On MapleDeploy, they all run on a single Starter instance. $45 CAD/month total, not $40-70 USD across three separate billing streams. If your experiments grow and you need more headroom, upgrade to Pro ($95 CAD/month, 8 GB RAM, 4 vCPUs) and keep deploying without restructuring anything. Connect your repo, push to a branch, and the platform builds and deploys automatically. Need Postgres? One click. Redis? Same. Real-time deployment logs, automatic SSL, custom domains. Our [Coolify deployment guide](/blog/deploy-app-coolify-guide) walks through the full workflow. ## The infrastructure decision AI builders skip Here's the part most AI-assisted development posts don't cover. Your code has to live somewhere. And where it lives is a [jurisdiction decision, not just a hosting decision](/blog/us-cloud-act-canadian-businesses). Most of the popular deployment platforms run on US cloud infrastructure. Railway's [deployment regions](https://docs.railway.com/deployments/regions) cover the US (California and Virginia), the Netherlands, and Singapore, with no Canadian option. [Render](/compare/render) is a US company with regions primarily in the US, plus Frankfurt and Singapore. Heroku runs on AWS. The parent companies are US-incorporated and subject to US data access laws regardless of which region you deploy to. MapleDeploy runs on [Canadian infrastructure](/canadian-hosting) in Toronto. That might not matter for a weekend experiment. But if the experiment turns into a real product with customer records that need to stay in Canada, you'll be glad the foundation was right from the start. Retrofitting data residency after launch is painful. It means migrating databases, updating DNS, re-provisioning infrastructure, and potentially re-architecting how your application handles data. Starting with Canadian infrastructure is free. Moving to it later is not. ## Open source underneath MapleDeploy runs on [Coolify](https://coolify.io), an [open-source platform](/open-source-stack) with 50,000+ GitHub stars. No proprietary runtime. No vendor lock-in. Your Dockerfiles and databases are standard. If you outgrow MapleDeploy or want to self-host, you take everything with you. Coolify supports a wide range of deployment methods out of the box. Push a Dockerfile and it builds and runs it. Push a Node.js, Python, or Go project and [Nixpacks](https://nixpacks.com/docs/getting-started) detects the language and builds automatically. Docker Compose files work directly. You can deploy static sites, full-stack frameworks, databases, and background workers from the same interface. This matters for AI-built projects specifically. AI tools generate standard code: Dockerfiles, package.json, requirements.txt. That code deploys to Coolify without modification. No platform-specific configuration files, no proprietary buildpacks to learn. A Next.js app that Claude Code scaffolded deploys the same way a hand-written one does. A Flask API that Cursor generated uses the same Dockerfile pattern you'd write yourself. The management layer is the difference between MapleDeploy and self-hosted Coolify. We handle the VM, operating system updates, security patches, backups, and monitoring. You get the flexibility of an open-source platform without the ops burden of maintaining the server it runs on. Self-hosting Coolify is a legitimate option if you enjoy server administration. But if you'd rather spend your time building and shipping, the managed version removes the distraction. Your AI coding tool generates the application. MapleDeploy runs it. --- AI tools changed what gets built. The deployment model needs to catch up. Per-project billing made sense when projects were expensive to create. Resource-based pricing makes sense when they're cheap to create and expensive to evaluate. MapleDeploy gives you a dedicated server on [Canadian infrastructure](/canadian-hosting), flat pricing starting at $45 CAD/month, and a 30-day free trial. Build five things this weekend. [Deploy all of them](/#pricing). {% cta-section title="Ship what you built" %} 30-day free trial. Push your repo, get a live URL. Plans start at $45 CAD/month. {% /cta-section %} --- ## Blog Insights on Canadian hosting, data sovereignty, and modern deployment. Practical guides for developers and teams building on Canadian infrastructure. URL: https://mapledeploy.ca/blog --- ## Migrating from Heroku to Coolify A practical guide to moving a Heroku app to Coolify. Concept mapping, config vars, Postgres migration with pg_dump, and a safe DNS cutover. URL: https://mapledeploy.ca/blog/migrate-heroku-to-coolify Date: 2026-08-27 Heroku made `git push` deploys normal. A generation of developers learned to ship on it, and the workflow it invented is still the one most platforms copy. If you're reading this, the platform probably isn't the problem. Something else changed: the bill, the resource ceiling, or where your data lives. [Coolify](https://coolify.io) is one of the places people land. It's an open-source deployment platform that runs on a server you control, with the same connect-a-repo-and-deploy model. This guide covers the concept mapping, the migration sequence, and the parts Heroku was doing for you that you'll now own. ## Why people migrate **Cost at scale.** Heroku bills per resource. A Basic dyno runs $7 USD/month for an always-on container, and Eco dynos share a pool of 1,000 dyno hours for $5 USD/month across your account, sleeping after a period of inactivity. Databases and add-ons are billed separately on top. None of that is unreasonable on its own. It's the addition that gets people: a web process, a worker, a database, a scheduler, a log drain, then the same again for staging. Check [Heroku's pricing page](https://www.heroku.com/pricing) for current figures before you model anything. **Dedicated resources.** Dynos are containers sized by tier. If you want more memory or CPU, you move up a tier. On Coolify, you're deploying onto a server whose specs you picked, and every app and database on it shares those resources on your terms. **Data residency.** Heroku's self-serve regions are US and EU. A Canadian region exists through Private Spaces, at a price point that rules it out for most teams. If your data needs to stay in Canada, that's a hard constraint rather than a preference. Our [full Heroku comparison](/compare/heroku) breaks down the side by side. ## Concept mapping Most of what you know transfers. The names change. | Heroku | Coolify | |---|---| | App | Application resource inside a project | | Dyno | Container running your application | | Procfile process types | One application per process, or a Docker Compose stack defining each service | | Buildpacks | Nixpacks (auto-detects your stack) or your own Dockerfile | | Config vars | Environment variables | | Heroku Postgres add-on | A PostgreSQL database resource you create on your server | | Heroku Scheduler | Scheduled tasks, defined with standard cron syntax | | Release phase | Pre-deployment and post-deployment commands | | Add-on marketplace | One-click services, or any Docker image you point it at | Two mappings deserve a note. **Release phase to deployment commands.** Coolify's pre-deployment command runs in the existing container before the new release goes out, and the post-deployment command runs in the newly built container afterward. Both are configured under the application's Advanced settings, and both execute with `sh -c`. Migrations that lived in your Procfile's `release` process type belong in the post-deployment command. Heroku ran release phase against the new slug, but Coolify's pre-deployment command runs against the old image, so a migration shipped in that same commit isn't in that container yet. Keep migrations backward compatible either way, because the new container starts serving before the post-deployment command finishes. **Scheduler to scheduled tasks.** Coolify's scheduled tasks run a command inside a container you name, on a cron schedule, and they accept the full five-field syntax plus named schedules like `@daily`. Worth knowing: they're container-scoped. Heroku Scheduler ran each job in its own one-off dyno, while Coolify execs into the running container, so your app has to be up for the task to fire. If you need something to run on the host rather than inside a container, that's not what this feature does. ## The migration sequence Do this in order. The point is that nothing is irreversible until the last step. 1. **Inventory what you have.** Run `heroku config -s` to dump your config vars and `heroku addons` to list every add-on. Write down your Procfile process types, any release phase command, your Scheduler jobs, and your custom domains. Lower the TTL on those DNS records now so the cutover is fast later. 2. **Stand up the app on Coolify from the same repo.** Connect your Git provider, create a project, add the repo as an application. If you have a Dockerfile, use it. If you were relying on buildpacks, start with Nixpacks and see how far it gets you. Our [Coolify deployment walkthrough](/blog/deploy-app-coolify-guide) covers build method selection, port configuration, and the gotchas. 3. **Port the environment variables.** Paste them in, minus the ones Heroku generated for you. `DATABASE_URL` and add-on credentials will be replaced with values from your own services. Watch for variables your framework needs at build time rather than runtime, since those need to be marked as build variables. 4. **Migrate the Postgres data.** Create a PostgreSQL database in Coolify first, then move the data. At a high level: `pg_dump` from your Heroku database connection string in custom format, then `pg_restore` into the new database with `--no-owner --no-acl` so it doesn't try to recreate Heroku's roles. Run `pg_dump` and `pg_restore` from a Postgres release at least as new as the newer of the two servers, since older client tools refuse to read a newer one. Do a throwaway run now to catch schema problems, and a final run at cutover. 5. **Test on the temporary URL.** Coolify gives every application a temporary URL before you attach a domain. Exercise the real paths: logins, background jobs, file uploads, scheduled tasks, anything that touches an external API. This is the step people rush, and it's the one that catches the missing environment variable. 6. **Cut over DNS.** Put the Heroku app in maintenance mode and scale any worker dynos to zero (maintenance mode only blocks web traffic; workers and Scheduler jobs keep running), take a final dump, restore it, then point your A record at your Coolify server. That combination is what makes the final dump consistent, so treat it as a planned write freeze and time the throwaway restore in step 4 to size it. With a low TTL, most traffic follows within minutes. Coolify provisions the Let's Encrypt certificate once DNS resolves. 7. **Keep Heroku running.** Don't delete anything for at least a week. Leave the app and its database in place, paying for it, until you've watched a full cycle of traffic, backups, and scheduled jobs run clean on the new setup. 8. **Decommission.** Remove add-ons, delete the app, cancel what's left. Keep one final Heroku backup somewhere off-platform before the database goes. ## What you take on Here's the honest part. Heroku does real work that becomes yours the moment you self-host. **Platform maintenance.** OS patches, Docker upgrades, Coolify updates, disk space, backup verification, uptime monitoring. Heroku did all of this invisibly and charged you for it inside the dyno price. On a VPS you rented yourself, it's your Saturday. **Buildpack behaviour.** Heroku's buildpacks encode years of accumulated knowledge about how specific frameworks want to be built. Coolify's automatic detectors, Nixpacks and Railpack, cover a lot of standard projects. When neither matches your setup, you're writing the Dockerfile yourself. That's more control and more work. **Add-on ecosystem.** Heroku's marketplace gives you third-party services with their own support and billing. On Coolify you deploy the equivalents onto your own server through one-click services or any Docker image. Broader coverage, but you're the one keeping them running. The maintenance half of that list is what a managed Coolify host takes back off you. The platform layer gets handled, and you keep the dedicated server and the open-source stack underneath. ## Where MapleDeploy fits MapleDeploy runs managed Coolify on [Canadian infrastructure](/canadian-hosting) in Toronto. We handle the VM, OS updates, security patches, monitoring, and weekly snapshots. You get the deployment platform without the server administration. Flat CAD pricing, starting at $45/month for a dedicated 4 GB VM with databases, SSL, and deploys included. Deploy as many apps and databases as the server can hold, with no per-resource billing to forecast. See [our pricing](/#pricing) for the full plan list. {% cta-section title="Move your first app over" %} 30-day free trial on Starter and Pro. Point Coolify at your repo, test on the temporary URL, cut over when you're ready. {% /cta-section %} --- ## Quebec's Law 25 and Canadian data residency Quebec's Law 25 is now fully in force. Here's what it requires, how Canadian data residency helps, and what compliance work still falls on you. URL: https://mapledeploy.ca/blog/quebec-law-25-data-residency Date: 2026-03-21 Quebec's **Law 25** (formally, An Act to Modernize Legislative Provisions as regards the Protection of Personal Information) [rolled out in three phases](https://www.blg.com/en/insights/2024/ri/quebec-law-25-still-has-more-to-say-answers-to-your-questions-on-the-new-data-portability-right) beginning September 22, 2022, with the final provisions (data portability) taking effect September 22, 2024. All requirements are now fully in force. If your organisation collects personal information about Quebec residents, the law almost certainly applies to you, regardless of where you're incorporated or hosted. This post covers what Law 25 actually requires, how [Canadian data residency](/canadian-hosting) affects your compliance posture, and where the responsibility still sits with you. This is not legal advice. If your organisation has significant Quebec operations or handles sensitive personal information, consult a Quebec privacy lawyer. ## What Law 25 is Law 25 is Quebec's modernisation of its [private-sector privacy legislation](https://www.canlii.org/en/qc/laws/stat/cqlr-c-p-39.1/latest/cqlr-c-p-39.1.html) (the Act respecting the protection of personal information in the private sector, in force since 1994). The reform was driven by the reality that the original law was written before smartphones, cloud computing, and large-scale data collection by private businesses. The updated law brings Quebec's framework closer to GDPR in scope and teeth. It introduces: - A requirement to designate a **privacy officer** (the person in charge of the protection of personal information) - Mandatory **privacy policies** written in plain language and published on your website - **Consent requirements** that are clearer and more explicit, particularly for sensitive data - **Privacy by default**: technology products and services offered to the public must have privacy settings set to the highest level of confidentiality by default, without any action by the user - **Privacy impact assessments (PIAs)** before deploying new information systems and before transferring personal information outside Quebec - A **privacy incident register** and mandatory notification to the **Commission d'accès à l'information (CAI)** and affected individuals for serious incidents - Individual rights: access, rectification, portability, and the right to de-indexation (similar to the right to be forgotten) ## Who it applies to Law 25 applies broadly to any enterprise that collects, uses, or communicates personal information about natural persons in the course of carrying on an enterprise in Quebec. That reach extends beyond Quebec-based businesses. If you serve Quebec residents, you are likely covered regardless of whether your company is incorporated in Ontario, British Columbia, or outside Canada entirely. There's no meaningful minimum-size exemption for most provisions. Small businesses are not automatically excluded. ## What Law 25 requires when personal information leaves Quebec This is the requirement most directly affected by where you host, and the one most often misread as a ban on foreign hosting. It is not a ban. It is an assessment obligation. Before communicating personal information to anyone outside Quebec (including to a third-party service provider outside Quebec), you must [conduct a privacy impact assessment](https://www.canlii.org/en/qc/laws/stat/cqlr-c-p-39.1/latest/cqlr-c-p-39.1.html) (section 17 of the Act) to evaluate whether the information would receive adequate protection in the destination jurisdiction. The transfer may proceed only if the assessment establishes that it would. Contractual and technical measures to mitigate identified risks feed into that assessment, and the communication has to be the subject of a written agreement that reflects the assessment's results. Adequacy is a gate, not an advisory finding. This applies even to cloud services. If your application is running on infrastructure hosted in a US data centre, or using US cloud services, that is a cross-border communication of personal information. You would need to conduct and document a PIA for that transfer, evaluate adequacy, and in many cases implement contractual protections. This is not a small task. PIAs require documented analysis of the destination jurisdiction's laws, the nature of the data being transferred, the security measures in place, and the residual risks. For US infrastructure in particular, you would need to address the [**CLOUD Act**](/blog/us-cloud-act-canadian-businesses). ## How Canadian data residency helps If your application data stays in Canada, under a Canadian hosting provider not subject to US jurisdiction, you largely sidestep the cross-border transfer problem for that data. When your application servers, databases, and file storage are in Canada, there is no cross-border transfer of personal information to assess for your core application data. The hardest part of the PIA requirement, the adequacy analysis for a foreign jurisdiction with different privacy laws, does not apply. MapleDeploy provides [dedicated Canadian infrastructure](/canadian-hosting) in Toronto. Each customer gets their own isolated VM, their own Coolify instance, and data that stays in Canada. That is the infrastructure piece of Law 25 compliance for your application data. We take our own Law 25 obligations seriously. MapleDeploy maintains a privacy incident registry, notifies the CAI as required for serious privacy incidents (see our [breach notification policy](/legal/breach-notification)), conducts PIAs before adding new sub-processors, and applies privacy by default in how we design our systems. You can review our [privacy policy](/legal/privacy) for details. ## What Canadian data residency does not cover It is important to be direct about this: Canadian data residency solves the infrastructure piece, not the whole compliance picture. Law 25 is broader than where your servers are. Your organisation still needs to: **Designate a privacy officer.** Someone must be formally accountable for personal information protection within your organisation. This is a named role, not a general responsibility. **Publish a privacy policy.** It must explain what information you collect, why, how you use and protect it, how individuals can exercise their rights, and how to contact your privacy officer. **Manage consent.** Collecting personal information requires valid consent. For sensitive categories of data, that consent must be explicit. Your application's consent flows, cookie notices, and data collection practices are your responsibility to design correctly. **Conduct PIAs for your own third-party tools.** Even with Canadian-hosted infrastructure, your application likely uses third-party services: payment processors, analytics tools, email providers, customer support software, and so on. Any of those that receive personal information from Quebec residents need their own adequacy assessment if they are outside Quebec. MapleDeploy handling the hosting does not relieve you of this obligation. **Govern data internally.** You need policies and procedures for how your team accesses, handles, and stores personal information. Training, access controls, and internal accountability are not infrastructure questions. **Respond to individual rights requests.** Access requests, correction requests, portability requests, and de-indexation requests require processes and designated ownership. **Handle privacy incidents.** If a privacy incident occurs that presents a risk of serious injury to an individual, you must notify the CAI and the affected individuals. You need a documented process for detecting, assessing, and reporting incidents. ## Penalties Law 25 penalties are significant. There are [two tiers](https://www.osler.com/en/insights/updates/law-25-a-new-enforcement-scheme-for-protection-of-personal-information-in-the-private-sector-in-que/). Administrative monetary penalties reach up to $10 million CAD or 2% of worldwide turnover for the preceding year, whichever is greater. Penal fines for more serious or intentional violations reach $25 million CAD or 4% of worldwide turnover, whichever is greater. The CAI can also order organisations to publish notices of violations at their own expense. There is also a private right of action. Since September 2023, section 93.1 requires a court to award punitive damages of at least $1,000 where an unlawful infringement of a right under the Act causes injury and is intentional or results from gross fault. PIPEDA has no equivalent. For smaller businesses, the more immediate risk is reputational and regulatory: a CAI investigation, a public order, or a mandatory notification to your users can be damaging well before penalties reach their ceiling. ## Where to start If your organisation serves Quebec residents and you have not started your Law 25 work, a reasonable starting point looks like this: 1. Map what personal information you collect, where it goes, and who touches it 2. Designate a privacy officer and document the role 3. Conduct PIAs for any cross-border data flows, starting with the most sensitive data 4. Review and update your privacy policy 5. Audit your consent flows and collection practices 6. Put a privacy incident response procedure in place Choosing Canadian infrastructure for your application removes one of the more complex items from that list: the cross-border transfer PIA for your core application data. That is a real reduction in compliance work and ongoing documentation burden. For the rest, consult legal counsel familiar with Quebec privacy law. The CAI also publishes guidance documents that are worth reading directly. --- If you are evaluating hosting options with Law 25 in mind, our [Canadian hosting overview](/canadian-hosting) covers the infrastructure and jurisdiction details in full. {% cta-section title="Canadian infrastructure, without the cross-border complexity" %} Your application data stays in Toronto. Try MapleDeploy free for 30 days. {% /cta-section %} --- ## Railway deploys easily, but your data stays in the US Railway simplifies backend infrastructure, but there's no escaping US jurisdiction. Here's why that matters for Canadian teams. URL: https://mapledeploy.ca/blog/railway-canadian-alternative Date: 2026-02-10 Railway is popular for backend developers. Connect a repo, get a database, deploy. But Railway is a US company on US infrastructure. If you're a Canadian team handling real data, that matters. ## The jurisdiction reality Railway runs on its own bare metal infrastructure across [four regions](https://docs.railway.com/reference/regions): US West (California), US East (Virginia), EU West (Amsterdam), and Southeast Asia (Singapore). There is no Canadian region. Railway itself is a [San Francisco-based](https://pitchbook.com/profiles/company/437879-53) US company, which means it's [subject to the CLOUD Act](/blog/us-cloud-act-canadian-businesses) regardless of where the data physically sits. Your API requests, database connections, and logs all flow through US systems. Even if you deploy to their EU West region, Railway is still a US company. The CLOUD Act follows the company, not the data center. A US court can compel Railway to produce your data whether it sits in California or Amsterdam. For Canadian teams, this means your data is governed by US legal process no matter which Railway region you choose. For side projects and internal tools, this doesn't matter. But if clients ask "where is our data?" then "US infrastructure, US company" may not work. ## The backend data problem Frontend hosting has an escape hatch: static sites don't store data. Backend services don't have that luxury. Your API endpoints receive user data. Your databases store it. Your logs capture it. With Railway, all of this lives on US infrastructure, stored by a US company. Consider the kinds of applications Canadian teams build on platforms like Railway. Client portals. Internal operations dashboards. B2B SaaS products where enterprise customers ask about data residency before onboarding. In each case, the backend is the part that touches customer data, and the backend is where jurisdiction matters most. It's not just regulated industries. Any SaaS product that stores client data will eventually face the question. A mid-size agency builds a client portal on Railway. Six months later, a prospective client sends over a security questionnaire asking where data is stored and which jurisdiction governs it. "US bare metal, US company" is a factual answer that may cost you the deal. If you have data residency requirements in contracts, or just don't want your infrastructure under US law, Railway can't help. ## Railway's pricing model Railway uses per-resource usage-based pricing. You pay a base subscription ($5 USD/month for Hobby, $20 USD/month for Pro, plus a limited free tier with $1 of monthly credits) that includes an equivalent amount of resource credits. After that, you pay for what you use: [roughly $20 USD per vCPU per month, $10 USD per GB of RAM per month, about $0.15 per GB of disk storage, and $0.05 per GB of egress](https://railway.com/pricing). This model works well for small projects with predictable, low resource usage. If your app barely touches its allocation, you pay only the base subscription. But backend services tend to grow. Add a PostgreSQL database, a Redis cache, a background worker, and a web server, and the per-resource charges stack up. A typical backend with a database can easily run $40-80 USD per month, and that's before traffic spikes. The challenge is predictability. With usage-based pricing, your bill changes month to month. A marketing campaign that drives a traffic spike, a client importing a large dataset, a background job that runs longer than expected. Each of these shows up on your invoice. For teams that need to forecast infrastructure costs or commit to a monthly budget, this creates friction. MapleDeploy uses flat pricing instead. The Starter plan is $45 CAD/month for a dedicated VM with 4 GB RAM, 2 vCPUs, and 35 GB storage. Deploy as many services and databases as you want within those resources. No per-project fees, no egress charges, no surprises. You know exactly what you'll pay before the month starts. ## Railway's database story Railway offers [one-click templates for PostgreSQL, MySQL, Redis, and MongoDB](https://docs.railway.com/guides/databases). The setup experience is genuinely good. Click a template, get a connection string, connect your app. No configuration files, no provisioning delays. The tradeoff is that those databases run as containers on Railway's shared infrastructure, billed per resource. Your PostgreSQL instance consumes RAM and CPU that count against your usage. If your database grows, so does your bill. And all of it runs on US infrastructure, which means your stored data is subject to US jurisdiction. With MapleDeploy, you get a full Coolify instance on a dedicated VM. Coolify supports one-click deployment of PostgreSQL, MySQL, Redis, MongoDB, and dozens of other services. The difference is that those databases run on your own VM in Toronto, on Canadian infrastructure, with resources that are yours regardless of how much or how little you use them. ## Migrating from Railway Moving off Railway is more straightforward than it might seem. Railway deploys from Docker or from a git repo using a Dockerfile or its zero-config builder ([Railpack](https://docs.railway.com/builds/railpack), which replaced Nixpacks). If your app runs on Railway, it almost certainly runs on any Docker-compatible platform. The migration path looks like this. Export your database using pg_dump (for PostgreSQL) or the equivalent for your database engine. Set up your services on MapleDeploy through Coolify's interface, which supports the same git-based deploy workflow. Import your database dump. Update your DNS records. The core application code doesn't change because Railway doesn't lock you into proprietary APIs for basic deployment. The one area that takes more thought is Railway's environment variable and service linking system. Railway auto-injects connection strings between services. On Coolify, you configure these explicitly through the dashboard. It's a few extra minutes of setup, but it means you can see and control every connection string rather than relying on platform magic. If you're using Railway templates for common stacks (Next.js + PostgreSQL, Django + Redis), the Coolify equivalent is two steps instead of one template: connect your repo, and Coolify detects the build, then add the database with one click. ## The Canadian alternative A Railway equivalent with Canadian jurisdiction needs: managed databases, git-based deploys, and servers physically in Canada operated by a Canadian company. See our [full Railway comparison](/compare/railway) for a side-by-side breakdown. MapleDeploy offers the same workflow (git push deploys, one-click databases, real-time logs) on [Canadian infrastructure](/canadian-hosting). Every customer gets a dedicated VM in Toronto. No shared containers, no noisy neighbors, no US jurisdiction over your data. The underlying platform is Coolify, an [open-source deployment tool](/open-source-stack) that provides the same developer experience Railway is known for. Git push triggers a build and deploy. Databases spin up in one click. Logs stream in real time. The difference is that it all runs on your own infrastructure in Canada, and you can see exactly how the platform works because the code is open source. For a step-by-step walkthrough, see our [getting started guide](/docs/deploy-your-first-app). We also cover [our full infrastructure stack](/blog/why-we-chose-canadian-first-infrastructure) and [payment processing tradeoffs](/blog/why-we-use-stripe) in dedicated posts. {% cta-section title="Same workflow, Canadian infrastructure" %} Git push deploys, one-click databases, real-time logs. 30-day free trial on Starter and Pro plans. {% /cta-section %} --- ## How to run several side projects on one server Run several side projects and databases on one server instead of paying per service. The general answer, what breaks when you consolidate, and how to size it. URL: https://mapledeploy.ca/blog/run-side-projects-one-server Date: 2026-09-02 Put them all on one server behind a deployment platform, and run one Postgres instance with a separate database per project instead of one database service per project. That's the whole answer. The rest of this post is the arithmetic that makes it worth doing, and the constraints that make it worth doing carefully. The problem you're solving is real. On per-service platforms, a web app plus a background worker plus a database is three separate line items. Five side projects built the same way is fifteen. Most of those projects get a handful of visitors a month. Paying full per-service rates on all of them is how a stack of hobby projects ends up costing more than rent. ## Why per-project billing adds up A few concrete examples, because "it adds up" is easy to say and hard to picture. On [Render](/compare/render), a Starter web service is $7 USD/month, a basic PostgreSQL database is $6 USD/month, and a background worker is another $7. One small project with a worker is already $20 USD/month before it has any traffic. Five projects built the same way, run separately, is $100 USD/month. Heroku deserves a caveat here, because it has one tier that genuinely is not per-app. The Eco plan is $5 USD/month for [1000 dyno hours shared across all your Eco dynos](https://devcenter.heroku.com/articles/eco-dyno-hours), and Eco dynos sleep after 30 minutes of inactivity without consuming hours. If your side projects really do get no traffic, that is the cheapest option on this page. Once you want anything always on, you are into a Basic dyno at $7 USD/month plus an Essential-0 Postgres add-on at $5 USD/month, billed per app. [Our Heroku comparison](/compare/heroku) has the fuller breakdown. On [Railway](/compare/railway), pricing is usage-based rather than per-app. Hobby is $5 USD/month including $5 of usage credit and Pro is $20 USD/month including $20, so usage is not additive until you spend the credit. Past it, the rates are roughly $20 USD per vCPU per month and $10 USD per GB of RAM per month. A database, a worker, and a web process each draw from that meter, so the bill is proportional to however many things you're running, not to how many servers they sit on. Supabase bills per project, not per server: the Pro plan is $25 USD/month and includes compute credits for one project, and [each additional project starts at roughly $10 USD/month](https://supabase.com/pricing). It is the same per-unit shape as the others, just counted in projects instead of services. None of these platforms are doing anything wrong. Per-service billing is honest and it scales down to zero for projects nobody visits. It's also expensive per project once you have more than one or two, because you're paying for isolation you don't need at hobby scale. ## The general answer: one server, one deployment platform in front of it Rent one VPS. Install a deployment platform on it, something like [Coolify](/open-source-stack), Dokploy, or CapRover. Deploy each project as its own app or Docker Compose stack. Run one Postgres instance (or MySQL, or both) as a long-running service, and give each project its own database and user inside that instance instead of its own database container. That's it. It's true whether you self-host that stack on any $10 VPS from any provider, or pay someone to run the server for you. The economics work the same way either way: you're paying for one machine's worth of resources instead of one bill per service. The part that actually needs care is what happens after you consolidate. ## What breaks when you consolidate **RAM is the binding constraint, not project count.** A dozen static sites and cron jobs cost almost nothing to run together. A dozen always-on Node or Python apps each holding their own connection pool and in-memory cache is a different story. Count what each project actually keeps resident in memory, not how many projects you have. **One server is one failure domain.** If the VM goes down, every project on it goes down at the same time. That's a real tradeoff against per-service platforms, where one provider's outage in one region doesn't necessarily take out every service you run there. For side projects, most people accept this trade happily. For anything a client or a paying user depends on, it's worth naming explicitly rather than discovering it during an incident. **Noisy neighbours become your own projects.** This is worth being precise about, because it's a different claim than the one hosting providers usually make. "No noisy neighbours" on a managed platform usually means no *other customer's* workload competes with yours. On your own consolidated server, your own projects are now each other's noisy neighbours. A runaway build, a memory leak, or an unbounded log file in project A can starve project B if nothing stops it. Docker resource limits (`mem_limit`, `cpus` in Compose, or your platform's equivalent) exist for exactly this and are worth setting once you have more than a couple of things running. **Backups matter more when everything is in one place.** Losing one server used to mean losing one project's database. Now it means losing all of them at once. Database-level backups (a scheduled `pg_dump` to S3-compatible storage, or your platform's built-in backup tool) and a way to rebuild the host itself are both worth having before you need them, not after. ## Sizing it: what a small app plus a database actually costs A useful way to size the box is to separate the fixed overhead from the per-project cost. The fixed cost is the operating system, Docker, and the deployment platform itself, running before you deploy anything. On a freshly provisioned MapleDeploy server, that baseline typically runs 0.7 to 0.8 GB of RAM. Whatever platform you use, expect something in that range: it's the price of admission before your own apps get a share. The per-project cost is smaller than people expect for low-traffic hobby projects. A small Node, Python, or Go API sitting mostly idle, with no meaningful traffic, usually holds well under a few hundred MB resident. A lightly used Postgres database serving one small project is typically similar, more if you raise `shared_buffers` or run heavier queries. So a "web app plus Postgres" pair for a low-traffic side project often fits comfortably in a few hundred MB total, and five or six of those together, plus the platform overhead, is a workload a 4 GB server can carry without drama. Traffic, background jobs, and anything holding a large cache in memory push those numbers up quickly, so treat this as a starting estimate to verify against your own project's actual memory usage under load, not a promise. One instance, many databases works fine for this. You don't need a separate Postgres container per project. Create one Postgres service, then `CREATE DATABASE project_a;`, `CREATE DATABASE project_b;`, each with its own user and credentials. It's the standard way to run several small apps against one database engine, and it's a lot lighter than running a database container per project. ## Mapping that to a plan Whatever platform runs the deployment side, you eventually need a server sized for the total, not the average. MapleDeploy's plans, all flat CAD per month with no per-project or per-service billing: | Plan | RAM | vCPUs | Storage | Price (CAD) | | --- | --- | --- | --- | --- | | Starter | 4 GB | 2 | 35 GB | $45/mo | | Pro | 8 GB | 4 | 70 GB | $95/mo | | Ultra | 16 GB | 6 | 125 GB | $195/mo | | Ultra 32 | 32 GB | 8 | 250 GB | $395/mo | | Ultra 64 | 64 GB | 8 | 500 GB | $695/mo | Starter and Pro include a 30-day free trial, so you can deploy your actual projects, watch real memory and CPU usage in the dashboard, and confirm the plan fits before paying for it. See [full pricing](/#pricing) for all tiers. ## Do I need a separate database service per project? No. One Postgres or MySQL instance with a database and user per project is the normal way to do this, and it's considerably lighter on RAM than a database container per project. Keep credentials separate per project so a bug or a leaked key in one app doesn't expose another project's data. ## Signs you're pushing the server too hard - Deploys start failing partway through a build, not because of your code but because the server ran out of memory mid-build. - One project's traffic spike visibly slows down an unrelated project on the same box. - Disk usage climbs steadily from accumulated Docker images, build cache, and old containers, not from your data growing. - You're checking whether the server is still up more often than you're shipping features. Any of those is a signal to set resource limits, move a project off, or size up, not to panic. It's normal maintenance for a shared box, the same way it would be for a shared database instance. ## If you'd rather not run the box yourself The self-hosted version of this is genuinely a good deal for a lot of people. It's also ongoing work: OS patches, platform updates, firewall rules, and backups, indefinitely. MapleDeploy runs managed Coolify on a dedicated VM in Toronto, and it's built around exactly this use case: one server, many apps and databases, one flat price. Each customer gets their own VM, not a shared container, so the "no noisy neighbours" part actually holds for cross-customer isolation. What you deploy on that VM, and how you divide its resources among your own projects, is still up to you. If you're starting from scratch, our [guide to deploying your first app](/docs/deploy-your-first-app) walks through connecting a repo and getting it live, and the same server takes your second and third project the same way. {% cta-section title="One server, as many projects as it fits" %} 30-day free trial on Starter and Pro. Flat CAD pricing, no per-project fees. {% /cta-section %} --- ## Self-host n8n on Coolify Deploy n8n on a Coolify server using the one-click service. Covers domains and SSL, the host and webhook URL variables, owner setup, persistence, and backups. URL: https://mapledeploy.ca/blog/self-host-n8n-coolify Date: 2026-08-24 n8n is a workflow automation tool. You wire together HTTP calls, database queries, API integrations, and scripts, then run them on a schedule or a trigger. It competes with Zapier and Make, with one difference that matters: you can run it on your own server. That is worth thinking about before you commit. Every workflow you build holds credentials for the services it touches: your CRM, your database, your email provider, your Git host. Every execution logs input and output data. On a hosted automation platform, all of that sits on someone else's infrastructure, on their schedule, under their jurisdiction. This post covers deploying n8n on [Coolify](https://coolify.io) using its one-click service catalog. If you have never deployed anything on Coolify before, start with our [Coolify deployment guide](/blog/deploy-app-coolify-guide) and come back. ## Why self-host it Three reasons, in rough order of how often they come up. **Your data stays where you put it.** Workflow definitions, connected-service credentials, and execution history all live in your n8n instance's storage. Nothing about a workflow run leaves your server unless the workflow itself sends it somewhere. **No per-execution pricing.** n8n Cloud bills against a monthly execution allowance per plan. That model is fine when volume is predictable, and awkward when it is not. A workflow that polls every minute burns through an allowance quickly. Self-hosted, your cost is the server, and the server does not care whether you run 500 executions or 500,000. **You control the version and the environment.** You decide when to upgrade, what environment variables to set, and what extra dependencies to install. One note on licensing: n8n is source-available under the **Sustainable Use License**, which n8n itself describes as fair-code rather than OSI open source. The license covers use for your own internal business purposes, plus personal and non-commercial use. Self-hosting your own workflows falls inside that. Providing n8n to others commercially does not, whether you resell it as a hosted service or build its functionality into a product you sell. That needs a separate agreement with n8n. Building workflows or nodes for paying clients is fine, and n8n explicitly permits commercial consulting and support services. Read the license before you plan around it. ## Step 1: create the service n8n is in Coolify's one-click service catalog, and Coolify maintains a dedicated docs page for it. That is the path this tutorial uses, because the template already sets the image, the networking, and the environment variables the container needs. In your project, add a new resource and choose Service, then search the catalog for n8n. Coolify offers several variants: - **n8n** on its own, which uses SQLite for storage - **n8n with PostgreSQL**, which adds a database container - **n8n with PostgreSQL and worker**, which adds a separate worker container and a Redis instance so executions run through a queue outside the main process The worker variant runs the most containers and is the one built for queue-based execution. If you are not sure which you need, the plain or PostgreSQL variants are simpler to reason about, and the catalog templates are just compose files you can edit later. ## Step 2: set the domain so SSL is issued Before you deploy, assign the service a domain. Coolify's proxy handles TLS with Let's Encrypt automatically once a domain is set and DNS resolves to your server. 1. Create an A record for the subdomain you want, for example `n8n.example.com`, pointing at your server's IP address. 2. In the service configuration, set that domain on the n8n container. 3. Deploy. This step is not cosmetic. n8n needs to know its own public address, and in a Coolify service the domain you assign is what feeds the variables that tell it. ## Step 3: check the host and webhook variables Coolify generates domain variables from the FQDN you assign. Two of them matter here: - `SERVICE_FQDN_N8N` is the hostname only, for example `n8n.example.com` - `SERVICE_URL_N8N` is the full URL including the protocol, for example `https://n8n.example.com` The n8n service template wires those into the variables n8n reads, including `N8N_HOST`, `N8N_PROTOCOL`, `N8N_EDITOR_BASE_URL`, and the webhook URL. Open the service's environment variables tab after you assign the domain and confirm the values look right. Pay attention to the difference between the two. A reported bug in the Coolify n8n template used to fill the editor base URL and webhook URL from the hostname-only variable, which broke OAuth callbacks on n8n 2.0 and later because those URLs need the `https://` prefix. That is fixed. All three templates now use the full-URL variable for both. One thing is still worth checking. The two PostgreSQL variants set `N8N_HOST` to the full-URL variable, so it arrives with an `https://` prefix on a variable n8n documents as a hostname. The plain variant uses the hostname-only variable, which is the correct one. Read your own values before you connect a Google, Microsoft, or LinkedIn credential, not after. ## Step 4: create the owner account immediately On first launch, n8n shows a setup screen and the first account created becomes the instance owner. n8n's docs specify a minimum of eight characters with at least one number and one capital letter. Do this the moment the deploy finishes. Until the setup is complete, anyone who can reach the instance can claim ownership of it. A public domain with a valid certificate is reachable by definition. ## How webhooks actually resolve n8n builds its webhook URLs from `N8N_PROTOCOL`, `N8N_HOST`, and `N8N_PORT`. Behind a reverse proxy, which is exactly what a Coolify service is, that calculation produces the internal address rather than your public one. n8n's docs cover this case directly: set the webhook URL explicitly so n8n displays the correct URL in the editor and registers the correct URL with external services. n8n's docs also note that `N8N_WEBHOOK_URL` replaces the older `WEBHOOK_URL`, and that the old name logs a deprecation warning. Templates in the wild still use the old name, so check which one your version expects. The symptom of getting this wrong is specific and confusing: the workflow fires from the test URL in the editor, and the production webhook never arrives. That is because the URL you handed to the external service points somewhere it cannot reach. ## Persistence, the encryption key, and updates Coolify services keep their data in Docker volumes, so stopping and starting a service does not wipe it. For n8n that means the data directory, and for the PostgreSQL variants the database volume as well. One thing to guard carefully. n8n generates a random encryption key on first launch, stores it in its `.n8n` data directory, and uses it to encrypt credentials before they are written to the database. Restore a database without that key and the credentials in it cannot be decrypted. You can set `N8N_ENCRYPTION_KEY` yourself instead of letting n8n generate one. That makes the key something you manage deliberately rather than something buried in a volume. To update, use the option in the service's UI to pull the latest images and restart. Pin a version tag in the compose file if you would rather control exactly when the version changes. ## Backups Coolify has scheduled database backups built in. On a database resource you set a cron schedule, a retention count, and an S3-compatible destination, and Coolify runs the dump for you. If you are on the PostgreSQL variant of the n8n service, that covers your workflows and execution history. Back up the encryption key and the n8n data volume separately. A database dump alone is not a complete restore. See our [backup guide](/docs/backups) for how this works on a MapleDeploy server and what we handle at the VM level. ## The Canadian angle Automation workflows tend to accumulate business data without anyone deciding that they should. A workflow that syncs orders holds customer records. A workflow that files support tickets holds whatever customers wrote. The credentials sitting in the instance often reach further than the workflows themselves. So decide deliberately what a workflow is allowed to touch. Our [acceptable use policy](/legal/aup) and terms rule some categories out entirely, including health and medical information, payment card data, and government-issued or financial account identifiers. n8n logs the input and output of every execution, so a workflow that only passes that data through still ends up storing it. MapleDeploy runs [managed Coolify](/open-source-stack) on dedicated VMs in Toronto. When you deploy n8n as a service on that server, the whole instance runs there: the container, the database, the execution history, and the encrypted credentials. No US intermediary, and no CLOUD Act exposure for your server and its data. See [Canadian hosting](/canadian-hosting) for the jurisdiction details. Each server is a dedicated VM, not shared infrastructure. Starter is 4 GB RAM and 2 vCPUs at $45 CAD/month, and you can deploy n8n alongside your other applications on the same Coolify instance. Which plan fits depends on how much you run. {% cta-section title="Run n8n on Canadian infrastructure" %} 30-day free trial on Starter and Pro. Deploy n8n from the Coolify service catalog on a dedicated VM in Toronto. {% /cta-section %} --- ## Self-hosting Coolify vs managed Coolify: how to choose An honest comparison of self-hosted Coolify, Coolify Cloud, and fully managed Coolify hosting. What each costs, what you maintain, and when each fits. URL: https://mapledeploy.ca/blog/self-hosted-vs-managed-coolify Date: 2026-08-12 You've used Coolify and you like it. Git push, automatic SSL, one-click databases, no per-seat pricing. The question now is not whether to use Coolify. It's who runs it. There are three answers, and they're often confused with each other. You can install Coolify yourself on a VPS. You can use Coolify Cloud, which hosts the control panel but not your apps. Or you can pay someone to run the whole thing, server included. They're priced differently because they're different products. Here's what each one actually involves. ## Option 1: self-host Coolify on your own VPS This is the default, and for a lot of people it's the right call. Coolify is [open source under Apache 2.0](/open-source-stack) and free forever when you host it yourself. You rent a VPS, run the single-command install script, and you have a working deployment platform. The only bill is the server. The install is easy. The part people underestimate is the next two years. **You own the operating system.** Kernel patches, package upgrades, reboots after a security advisory. Unattended upgrades cover some of it. Some of it needs you. **You own Coolify updates.** Coolify checks for new versions on a schedule and shows an upgrade button in the dashboard. You can pick automatic, semi-automatic, or fully manual updates. Coolify's own documentation recommends disabling automatic updates on production instances, which means the update decision comes back to you, along with the job of reading release notes before pressing the button. **You own the security posture.** Firewall rules, SSH key authentication, closing the ports the install script didn't. A fresh VPS with a public IP starts getting scanned within minutes. **You own disk pressure.** This is the failure mode that bites self-hosters most often. Docker images, build cache, stopped containers, and old volumes accumulate until a deploy fails at 3am with no space left on device. Coolify has good tooling for this. Automated Docker cleanup runs on a cron schedule, or when disk usage crosses a threshold you set under Servers, Configuration, Advanced. It removes stopped containers, unused images, and build cache. You still have to turn it on and pick sensible values. **You own backups.** Coolify can back up your databases to any S3-compatible storage on a schedule with a retention policy. It doesn't back up the server itself. If the VM is lost, you're rebuilding the host, reinstalling Coolify, and restoring from those dumps. That works, if you've tested it. **You're on call.** Not in a pager-duty sense, but in the sense that when your side project's Postgres container won't come back up on a Saturday, the person fixing it is you. None of this is hard. It's just never finished. Self-hosting on a $10 VPS is genuinely a great deal if you enjoy that work, or if your monthly hosting budget matters more than your weekends. Plenty of excellent projects run exactly this way. ## Option 2: Coolify Cloud Coolify Cloud is the part people most often misread, so it's worth being precise. Coolify Cloud hosts the **control panel**. The Coolify instance itself runs on Coolify's infrastructure, maintained by the Coolify team, with community support plus limited email support. You don't allocate CPU, RAM, or disk to running Coolify, and you don't maintain the Coolify application. You still bring your own servers. You connect a VPS, an EC2 instance, or a Raspberry Pi over SSH, and your applications deploy onto that machine. Pricing is $5 USD/month for the base plan covering up to two connected servers, plus $3 USD/month for each additional server, on top of whatever you pay your VPS provider. Here's the boundary that matters: Coolify Cloud manages the Coolify instance, not your server. The operating system, the firewall, the disk, the security updates on the machine your apps run on, all still yours. So Coolify Cloud removes one item from the self-hosting list above. It's a good deal at $5/month for what it does. Just don't buy it expecting the server maintenance to go away, because that isn't what it's for. ## Option 3: fully managed Coolify The third option is paying for the server and its upkeep together. That's what MapleDeploy does. You get a dedicated VM in Toronto with your own Coolify instance on it. Not a shared container on someone else's box. Your own VM, with dedicated RAM, CPU, and storage. What's handled for you: - **Provisioning.** Pick a plan, and the server is ready in minutes. - **Security hardening.** SSH key authentication, fail2ban, outbound SMTP blocking, and automatic security patches, applied before you first log in. - **OS patches and maintenance.** Operating system updates and kernel patches are applied for you. No SSH sessions to schedule. When a kernel update needs a reboot, it happens in a fixed 08:00 UTC window, typically once every few weeks. - **Coolify itself.** MapleDeploy runs a public fork of Coolify that we rebase regularly against upstream. Changes are limited to Canadian branding and MapleDeploy integrations, and you can read the diff. - **Snapshots.** Weekly full-server snapshots covering the OS, Coolify, containers, volumes, and databases, plus a snapshot taken before any VM termination and retained for 30 days after cancellation. - **Monitoring.** CPU and memory metrics stream into the Coolify dashboard. Nothing third-party to wire up. Two honest caveats. First, snapshots are disaster recovery, not granular restores. A snapshot can be up to seven days old. For production databases you should still configure Coolify's S3 database backups on a daily schedule. Two layers, different jobs. Second, MapleDeploy is self-service, not a consulting arrangement. We run the server. You deploy your apps, configure your domains, and manage your databases through the Coolify dashboard. If you need someone to architect your deployment for you, you want a DevOps consultant, and MapleDeploy is the platform they'd deploy onto. ## The other axis: where your data lives Cost and effort are the obvious comparison. Jurisdiction is the one that decides it for some readers. Self-hosting lets you put Coolify anywhere, including a Canadian provider, so this isn't an argument against it. But most of the cheap, popular VPS options developers reach for are US-owned or US-hosted, which puts your data within reach of the **CLOUD Act** regardless of which city the machine sits in. MapleDeploy runs on [Canadian infrastructure](/canadian-hosting) in Toronto, with a privately owned Canadian provider that has no US parent company. Your code and your data stay under Canadian law, on infrastructure built for **PIPEDA** compliance. If that matters to you on principle or to your clients in procurement, it's included on every plan rather than sold as an add-on. ## How to actually decide A rough decision rule: - **Self-host** if hosting cost is your binding constraint, you're comfortable on a Linux box, and an occasional weekend fixing your own infrastructure sounds fine. This is the honest answer for most hobby projects and side projects. - **Coolify Cloud** if you're already managing servers you're happy with and you just don't want the Coolify instance to be one more thing to patch. - **Fully managed** if your time is worth more than the price difference, if something is running that customers depend on, or if you need your data in Canada without auditing a VPS provider's ownership structure. The comparison isn't $10 versus $45. It's $10 plus your evenings versus $45. Some months that's an easy call in one direction, some months in the other. MapleDeploy starts at $45 CAD/month for a dedicated Toronto VM with 4 GB RAM, 2 vCPUs, and 35 GB of storage, flat, with no per-project or usage fees. See [pricing](/#pricing) for the full range of plans. Starter and Pro include a 30-day free trial, which is enough time to deploy something real and find out whether the managed version is worth it to you. If you'd rather start by seeing how Coolify deploys work, our [Coolify deployment guide](/blog/deploy-app-coolify-guide) walks through a full app from repo to custom domain. That workflow is identical whichever option you pick, which is exactly the point of building on open source. {% cta-section title="Try the managed version" %} 30-day free trial on Starter and Pro. Deploy a real project, see if it fits. {% /cta-section %} --- ## The US CLOUD Act: what Canadian businesses should know The CLOUD Act lets US courts compel American companies to produce data regardless of where it's stored. Here's what Canadian businesses should know. URL: https://mapledeploy.ca/blog/us-cloud-act-canadian-businesses Date: 2026-01-13 Here is the part many Canadian businesses miss: **PIPEDA** cannot protect your data from American law. If your hosting provider is a US company, a US court can compel that company to produce data under the **CLOUD Act**, even if the servers are in Toronto. The legal framework follows the company, not just the data center. This is not legal advice. It is the hosting risk in plain language: if your clients, regulator, or contracts care about Canadian jurisdiction, "stored in Canada" is not always enough. ## What the CLOUD Act does In 2018, the United States passed the Clarifying Lawful Overseas Use of Data Act, enacted as Division V of the [Consolidated Appropriations Act, 2018](https://www.law.cornell.edu/uscode/text/18/2713) and codified at 18 U.S.C. section 2713. It gives US law enforcement a way to compel American companies to produce data, regardless of where that data is stored. If the provider is subject to US jurisdiction, the location of the server does not remove the exposure. That does not mean every request is blanket surveillance. Content data generally requires stronger legal process than basic subscriber information. Companies can challenge requests, especially when compliance conflicts with another country's laws. The practical problem is still real. Challenging a government request is expensive, slow, and uncertain. Most Canadian teams do not want their hosting risk to depend on whether a US provider decides to fight a US court order. The CLOUD Act also created a framework for executive agreements between the US and other countries. The US has agreements with the UK and Australia, and [Canada-US negotiations were announced in March 2022](https://www.justice.gov/archives/opa/pr/united-states-and-canada-welcome-negotiations-cloud-act-agreement). That is important context, but it does not change the core issue. US companies are already subject to US law. ## Why PIPEDA is not enough PIPEDA governs what Canadian organizations must do with personal information. It does not control what a US court can compel a US company to do. If you host with a US-jurisdiction provider, your privacy policy, data residency policy, vendor contract, and PIPEDA compliance do not override a US court order directed at that provider. The Government of Canada has acknowledged this problem in its [white paper on data sovereignty and public cloud](https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/cloud-services/digital-sovereignty/gc-white-paper-data-sovereignty-public-cloud.html). A cloud provider with foreign operations may have to comply with foreign warrants, court orders, or subpoenas, sometimes without notice to the Government of Canada. That is why Canadian jurisdiction matters. Hosting with a Canadian-owned provider that keeps the relevant data on Canadian infrastructure and has no US application-data dependency generally means foreign data requests go through Canadian legal channels, rather than a direct order to a US-jurisdiction provider. ## Provincial laws raise the stakes Provincial laws do not block the CLOUD Act either. They do make provider choice harder to justify when personal information is sensitive. - **Quebec Law 25:** Transfers of personal information outside Quebec require a privacy impact assessment. Hosting with a US provider means that assessment has to account for CLOUD Act exposure. - **Ontario PHIPA:** Health information custodians face strict expectations for patient data. A US-jurisdiction hosting provider creates a risk that needs to be documented and justified. Canadian jurisdiction alone does not settle it either. Health workloads need a provider prepared to sign health-privacy service-provider terms and operate the required controls, which MapleDeploy does not do. - **BC PIPA and FIPPA:** Private organizations and public bodies have separate requirements, but both make cross-border handling of personal information a serious governance question. The pattern is consistent: these laws do not make Canadian-only hosting mandatory for every business, but they make jurisdiction a real risk factor. ## When this matters For a personal blog, this probably does not matter. For some businesses, it matters a lot: - A client portal storing project files and messages. - A law firm storing routine client correspondence. - A business services team managing customer contacts and project notes. - An agency responding to government RFPs with data residency requirements. - A SaaS company whose customers ask where data lives and whose law governs it. The concern is not "can any government ever access data?" No jurisdiction is a perfect shield. Canada and the US have treaty processes for lawful access. The concern is "which legal process governs access?" A Canadian court process is different from a US court order sent directly to a US provider. ## What Canadian jurisdiction does and does not solve Canadian data sovereignty means more than "servers in Canada." It usually requires: - Canadian infrastructure, so the data is physically stored in Canada. - Canadian jurisdiction, so the service provider is governed by Canadian law. - No US cloud dependency for the application data layer. This is not an impenetrable shield. Canadian courts can cooperate with foreign governments through treaties and judicial assistance. A small Canadian provider also has fewer legal resources than a hyperscaler. What Canadian jurisdiction gives you is a clearer legal framework. Requests for customer application data go through Canadian legal process instead of directly through a US provider subject to US law. ## Questions to ask hosting providers When evaluating hosting providers, ask direct questions: - Who owns the service, and where is the parent company incorporated? - Is the underlying compute, storage, or network run by a US cloud provider? - Can the provider give you a written data residency attestation? - What is their policy for foreign government data requests? - Will they notify customers when legally allowed? - Do payment, email, analytics, or support tools touch customer application data? The answers matter more than a Canadian flag on the homepage. ## Where MapleDeploy fits MapleDeploy is [Canadian-owned and operated](/canadian-hosting), with customer VMs on Canadian infrastructure in Toronto. Your application data, databases, server configuration, and Coolify instance stay in Canada. We are also honest about the boundary. Payment processing uses Stripe, a US company, for PCI compliance reasons. We offer Interac e-Transfer as a Canadian payment alternative. See [why we use Stripe](/blog/why-we-use-stripe) for the tradeoff. If Canadian jurisdiction matters to your project, evaluate the full stack, not just the region label. MapleDeploy gives you git push deploys, managed Coolify, and Canadian infrastructure without putting your application data on a US cloud provider. {% cta-section title="Canadian jurisdiction by default" %} Your application data, hosted in Canada. Try Starter or Pro free for 30 days. {% /cta-section %} --- ## Vercel's hidden jurisdiction risk for Canadians Zero-config deployments are great until you need to guarantee where your data lives. Why Canadian teams are looking beyond Vercel. URL: https://mapledeploy.ca/blog/vercel-canadian-alternative Date: 2026-02-24 You're a Canadian developer building with Next.js. You've got API routes handling user data, server components rendering personalized content, maybe a database connection or two. Vercel makes deploying all of this effortless. But there's a question your compliance team, your clients, or your own instincts might eventually raise: where does that data actually live, and whose law governs it? ## Next.js doesn't require Vercel Vercel makes Next.js, and Next.js is excellent. But the two are separable. Next.js has a built-in standalone output mode designed specifically for self-hosting. Set `output: "standalone"` in your `next.config.js` and Next.js produces a self-contained folder with a minimal Node.js server and only the `node_modules` your app actually imports. No full dependency tree, no bloat. That standalone output drops neatly into a multi-stage Docker build. The standard pattern is three stages: install dependencies, build the app, copy the standalone output into a minimal runner image. The resulting Docker image is typically under 200 MB, down from over 2 GB with a naive build. It runs anywhere Docker runs, which means any VPS, any Kubernetes cluster, any PaaS that supports containers. You lose some Vercel conveniences (analytics, Global Config), but you gain control over where your code runs and whose jurisdiction covers your data. For teams that only use Vercel for deployments, the switch is straightforward. For teams deeper into the Vercel ecosystem, it takes more effort, but it's not a rewrite. ## The Montreal region doesn't solve the jurisdiction problem Vercel now offers a [Montreal region (yul1)](https://vercel.com/docs/regions) for serverless functions, which helps with latency. But a Canadian compute region is not Canadian jurisdiction. Vercel is a [US company headquartered in San Francisco](https://vercel.com/about) [subject to the CLOUD Act](/blog/us-cloud-act-canadian-businesses) regardless of which region you select. Your API routes and server components handle real data, and that data is governed by US law. Vercel's infrastructure [runs on AWS](https://vercel.com/blog/aws-and-vercel-accelerating-innovation-with-serverless-computing). The [default function region](https://vercel.com/docs/regions) for new projects is Washington, D.C. (iad1). You can change it to Montreal, but the platform itself, your account data, your deployment metadata, your logs, all of that flows through Vercel's US-based systems. Choosing a Canadian compute region changes where your function executes. It doesn't change which country's courts can compel Vercel to hand over your data. If your concern is latency alone, Vercel's Montreal region solves that. If your concern is the legal framework governing your data, it doesn't. ## Who should care The obvious cases are teams with data residency commitments. A B2B SaaS product with Canadian enterprise customers needs Canadian jurisdiction, not just Canadian latency. An agency portal where clients upload project materials cannot afford ambiguity about which country's courts can access those documents. But compliance isn't the only driver. Consider a B2B analytics tool that ingests client data to generate reports. The tool itself isn't regulated, but the clients are. When an enterprise prospect sends over a security questionnaire asking where their data is stored and which jurisdiction governs it, "US company, AWS infrastructure" is a factual answer that may cost you the deal. Government contractors face this directly. Federal and provincial procurement increasingly requires Canadian data residency, and that means Canadian jurisdiction, not a US company with a Canadian region option. Static marketing sites with no user data? Vercel is fine. But once you add API routes, form submissions, or a database, you're making a jurisdiction choice whether you realize it or not. ## Vercel's pricing adds up Vercel's [Pro plan](https://vercel.com/pricing) starts at $20 USD per user per month. That base price includes one deploying member and a $20 usage credit. Each additional team member who can deploy costs another $20 per month. Viewer seats are free, but anyone who needs to trigger a deployment or manage settings pays. The usage model layers on top. Pro includes 1 TB of data transfer per month. After that, [Fast Data Transfer overage rates range from $0.15 to $0.35 per GB depending on region](https://vercel.com/docs/pricing/regional-pricing). Serverless compute (Vercel calls it [Fluid Compute](https://vercel.com/docs/functions/usage-and-pricing)) is billed across three dimensions: active CPU time, provisioned memory, and invocations, with pay-as-you-go overages beyond the $20 usage credit. Image optimization, analytics, and storage products each have their own usage tiers and overage pricing. For a solo developer with a single project, Vercel Pro is reasonable. For a team of five deploying multiple projects, the per-seat costs alone reach $100 USD per month before any usage charges. Add bandwidth overages from a traffic spike, heavier serverless function usage, or a few storage products, and the monthly bill becomes hard to predict. MapleDeploy uses flat pricing. The Starter plan is $45 CAD per month for a dedicated VM with 4 GB RAM, 2 vCPUs, and 35 GB storage. Deploy as many Next.js apps, backends, and databases as your resources allow. No per-seat fees, no bandwidth overages, no serverless execution metering. Your bill is the same every month regardless of traffic or team size. ## What you give up Being honest about tradeoffs matters. Vercel has genuine advantages that don't have direct equivalents on a self-hosted platform. Vercel's edge network delivers static assets from locations worldwide. On MapleDeploy, your app serves from a dedicated VM in Toronto. For Canadian and North American audiences, that's fast and your data stays in Canadian jurisdiction. For a global consumer app, put Bunny.net or Cloudflare in front of your VM and you get edge delivery with a Canadian origin. Vercel Analytics and Speed Insights provide real user monitoring tied directly to your deployments. Self-hosted alternatives exist (Plausible, Umami, PostHog), but you set them up yourself. Global Config (formerly Edge Config) is convenient for feature flags. For session data or caching, Vercel's marketplace offers Redis integrations through Upstash. On Coolify, you'd deploy Redis or use an equivalent service. Vercel's preview deployments for every pull request are polished. Coolify gives you the same thing: every PR gets its own preview URL with automatic cleanup when the PR closes, managed from the Coolify dashboard. None of these are dealbreakers. They're conveniences. The question is whether those conveniences justify US jurisdiction over your data. ## What a practical migration looks like If you decide to move, the process is more mechanical than architectural. Your application code barely changes. Start with your `next.config.js`. Add `output: "standalone"` if it's not already there. Run a build locally and verify the `.next/standalone` directory is produced. If your app builds successfully in standalone mode, it will run on any Node.js host. Next, write a Dockerfile. Next.js provides an official example in their repository. The pattern is straightforward: install dependencies, build the app, copy the standalone output and static assets into a slim final image. The official example runs about 110 lines, including comments, a non-root user, and a slim base image. A stripped-down version is much shorter. Move your environment variables. On Vercel, these live in the project settings dashboard. On Coolify, you configure them in the application settings. Same key-value pairs, different UI. If you're using Vercel-specific environment variables like `VERCEL_URL`, replace them with your actual domain. For databases, the migration depends on what you're using. If your database is already external (Neon, PlanetScale, Supabase), you just update the connection string to point to your new infrastructure. If you're using a Vercel Marketplace database (Neon Postgres, Upstash Redis), you can either keep the external provider and update the connection string, or migrate to a self-hosted PostgreSQL or Redis instance on Coolify. Coolify supports one-click deployment of both. DNS is the last step. Point your domain to your new server. If you're using Vercel's automatic SSL, Coolify handles Let's Encrypt certificates automatically. The whole process for a typical Next.js app with a database takes an afternoon. The codebase doesn't change in any meaningful way. What changes is where it runs and whose law governs it. Our [getting started guide](/docs/deploy-your-first-app) covers the full MapleDeploy setup from signup to a live app. ## Deciding whether to move What Vercel features do you actually use? If it's just deployments, alternatives are straightforward. If you're deep into Vercel Analytics and Global Config, migration takes more effort. Do you need edge performance? For most B2B applications, single-region deployment from Toronto is fast enough for North American users. Edge only matters for global consumer traffic. Be clear about your compliance requirement. "We should probably care" is different from "our contracts require it." The latter justifies more migration effort. But don't wait for a compliance requirement to be the forcing function. Some teams move because they want a clear answer when a client asks "where is our data?" A proper Canadian alternative needs: [Canadian jurisdiction](/canadian-hosting) (not just a Canadian data center), full-stack support (server components, API routes, databases), and a modern developer experience. MapleDeploy delivers all of these. See our [full Vercel comparison](/compare/vercel) for a side-by-side breakdown. {% cta-section title="Next.js without the jurisdiction tradeoff" %} Deploy your full stack on Canadian infrastructure. 30-day free trial, flat pricing. {% /cta-section %} --- ## Why we chose Canadian-first infrastructure Every modern hosting platform runs on US infrastructure. We built MapleDeploy on Canadian and EU providers instead. Here's the full stack and the tradeoffs. URL: https://mapledeploy.ca/blog/why-we-chose-canadian-first-infrastructure Date: 2026-03-24 Open a new AWS account and the default region is `us-east-1`. Spin up a DigitalOcean droplet and the first option is New York. Deploy to Railway, Render, or Vercel and your application data lands on US servers by default, sometimes without a way to change it. Nobody questions this. US infrastructure is the path of least resistance. It's cheaper, better-documented, and has more community support than any alternative. If you're building a startup and you need to ship fast, you reach for AWS. We understand that choice. We made a different one. The goal was to build a managed hosting platform where we could honestly tell customers: your application data doesn't leave Canada. Every layer of the stack is documented, including the places we had to compromise. ## Jurisdiction, not just geography Most "Canadian hosting" providers blur an important distinction. A US company can rent space in a Toronto data center and tell you your data is in Canada. That's true in the geographic sense. It's not true in the legal sense. **Jurisdiction is determined by where the company is incorporated, not where the servers sit.** In 2018, the US passed the **CLOUD Act** as [Division V of the Consolidated Appropriations Act, 2018](https://www.congress.gov/115/plaws/publ141/PLAW-115publ141.pdf), now codified at 18 U.S.C. section 2713, which [amends the Stored Communications Act](https://www.justice.gov/criminal/cloud-act-resources) to make explicit that US service providers must preserve and produce data they control regardless of where it is physically stored. Toronto, Frankfurt, Sydney. If the company is incorporated in the US, a US court can issue a warrant or order for data access. Before the CLOUD Act, a US company could argue that data in a Canadian data center was outside US jurisdiction. That argument is largely gone. CLOUD Act requests aren't blanket surveillance. Content requests require a warrant. Subscriber records and non-content can come by subpoena, with no court order. Providers can move to quash under section 2703(h), but only where the subscriber is not a US person and the request would conflict with the law of a government that has a CLOUD Act executive agreement in force. Canada does not have one. Negotiations were announced in March 2022 and have not concluded. Our read is that in practice most companies comply, because challenging any request is expensive. This applies to AWS, GCP, Azure, [Heroku](/compare/heroku), [Railway](/compare/railway), [Render](/compare/render), [Vercel](/compare/vercel), and [Fly.io](/compare/fly). They're all excellent products. They're all US-incorporated companies. True data sovereignty requires three things: Canadian infrastructure (physical servers in Canada), Canadian jurisdiction (the hosting company is subject to Canadian law, not US law), and no US cloud dependencies underneath. Many providers get one or two of these. Getting all three requires actually building on Canadian-owned infrastructure. ## The stack we chose Every layer of the platform required a decision about provider jurisdiction. Here's what we landed on and why. **Customer VMs run on [LunaNode](https://www.lunanode.com/)**, a BC-incorporated company ([Corporate Registry #BC0997033](https://opencorporates.com/companies/ca_bc/BC0997033)) that operates its own infrastructure in a Toronto data center. Privately held, no US parent, no hyperscaler under the hood. We confirmed this directly with LunaNode. When a customer's application data sits in a LunaNode VM, it's in Canada in a meaningful sense, not just in a Canadian data center leased from Amazon. **DNS is managed through [Bunny.net](https://bunny.net/)**, a Slovenian company. EU-headquartered, GDPR-bound, no US parent. Not Canadian, but EU jurisdiction is a reasonable second choice. Bunny also handles our CDN for the marketing site. It only serves publicly cached content, specifically our marketing site assets and Coolify update files. No customer application data passes through it. **Transactional email goes through [Cakemail](https://www.cakemail.com/)**, a Montreal company. Server-ready notifications, billing reminders, trial expiry warnings. All processed in Canada. **Business email is on [mailbox](https://mailbox.org/)** (formerly Mailbox.org), a German provider. German data protection law is strict by default. Not Canadian, but German jurisdiction is well understood and the alternative, Google or Microsoft, means US law applies to every email in your inbox. **Our domain registrar is [CanSpace](https://www.canspace.ca/)**, a Canadian company and accredited .ca registrar. The .ca TLD is operated by [CIRA](https://www.cira.ca/), a Canadian nonprofit. We also use CIRA's Canadian Shield as our DNS resolver: a free, privacy-respecting resolver operated by the same organization that runs the .ca registry. **Secrets management is [1Password](https://1password.com/)**, which is headquartered in Toronto. All API keys, credentials, and deployment secrets live there. **The deployment platform itself is [Coolify](https://coolify.io/)** ([our stack](/open-source-stack)), open source software we self-host on LunaNode. No data leaves our infrastructure for platform licensing. We manage the Coolify installation and keep it updated. **Database is PostgreSQL**, self-hosted. Same story. Two operational services are US-incorporated. **Better Stack** runs our uptime checks and status page, with data stored in EU regions. **Let's Encrypt** issues our certificates and receives only domain names. Neither sees customer application data. That's the stack. Canadian or EU jurisdiction for everything that touches application data, application data in Canada exclusively, no US hyperscaler dependency for infrastructure. Learn more about our [Canadian hosting approach](/canadian-hosting). ## The payments compromise The obvious choice for a Canadian business accepting recurring payments was [Helcim](https://www.helcim.com/). Calgary-based, interchange-plus pricing that's genuinely transparent, a well-documented API, subscription support. On paper, the right call. We applied and were rejected. Helcim's [acceptable use policy](https://legal.helcim.com/ca/acceptable-use-policy/) lists "website hosting (if it is the sole service offering)" as prohibited and website hosting bundled with other services as restricted. Payment processors use broad merchant category codes, and "hosting" is restricted by some acquirers. The same code covers everything from shared hosting to enterprise cloud, with no distinction between a managed PaaS and a file storage service. We understand the reasoning. Payment processors manage portfolio risk, and broad categories are how they do it. But it creates an unfortunate outcome: a Canadian business built specifically to keep data on Canadian infrastructure can't use a Canadian payment processor because of a category code. So we use **[Stripe](https://stripe.com/)** for automated billing. Stripe is a US-headquartered company. Payment data is processed in US data centers and is subject to US jurisdiction. We've written about this decision in more detail in [our Stripe post](/blog/why-we-use-stripe), including what it does and doesn't mean for PIPEDA compliance. The short version: payment data crosses the border, application data does not. For customers who want payments to stay in Canada, **we accept Interac e-Transfer**. Interac is a Canadian interbank network. E-transfers between Canadian financial institutions are processed domestically. The tradeoff is that it's manual: you receive a monthly invoice and send payment directly. No automated billing or self-service portal. If that's the right fit, contact us at hello@mapledeploy.ca. We'd like to revisit this with Helcim as we build a track record. They have a review process for restricted categories, and we'll apply again once we have some history. ## The tradeoffs This is not a free choice. There are fewer infrastructure providers in Canada than in the US. We can't spin up a managed RDS instance, an ElastiCache cluster, or dozens of other AWS services. Every tool we add to the stack requires checking its jurisdiction before we can use it. Services we'd otherwise reach for automatically are off the table. LunaNode is excellent, but it's not AWS. The managed service ecosystem in Canada is smaller, community resources are thinner, and some per-unit costs are higher. Payments are the biggest gap. Canadian payment processors exist, but the ones with mature APIs either classify hosting as restricted or don't offer the subscription lifecycle tooling a managed service needs. "Website hosting" as a flat prohibition doesn't distinguish between a cyberlocker and a managed PaaS. That's a problem the Canadian payments industry would benefit from revisiting as more Canadian software companies try to build on Canadian infrastructure. The ecosystem is getting better. Companies like LunaNode and Cakemail exist and work well. CIRA has built infrastructure worth using. We'd rather build on the right foundation now than migrate later. We maintain a [Canadian SaaS stack](/canadian-saas-stack) resource that catalogues the options by category. ## Who this is for **Developers who prefer Canadian infrastructure.** You don't need a regulatory reason. Preferring that your tools and data stay under Canadian jurisdiction is reason enough. MapleDeploy gives you a [modern PaaS](/git-push-deploys) that happens to be on Canadian soil. **Businesses with data residency requirements.** Client portals, agency workflows, internal tools, and SaaS products whose customers ask where the data lives. You need a clear answer. The [compliance documentation](/legal) is there when you need it. Workloads that require sector-specific contracts or controls need a provider set up for those obligations. If you're hosting a portfolio site with no data obligations and no preference either way, use whatever is cheapest. AWS is fine. Vercel is fine. We built MapleDeploy because we wanted managed Coolify with a clear, honest answer to "where is my data and whose law governs it." The answer is Canada and Canadian law. We should be honest about the limits of that. Canadian jurisdiction means data requests go through Canadian courts, but Canadian courts do cooperate with foreign governments through MLATs and judicial assistance. And as a small company, we have fewer resources to challenge government requests than a large enterprise. What we can offer is a clear legal framework: Canadian law governs your data, and we'll be transparent about any requests we receive. If you're building something and you've found a Canadian payment processor that handles managed hosting businesses with real subscription tooling, we're at hello@mapledeploy.ca. --- MapleDeploy runs on LunaNode infrastructure in Toronto. Plans start at $45 CAD/month with a 30-day free trial on Starter and Pro plans. If Canadian data residency matters to what you're building, [take a look](/#pricing). {% cta-section title="See what Canadian-first hosting looks like" %} Dedicated VMs on Canadian infrastructure. Deploy a real project during your 30-day free trial. {% /cta-section %} --- ## Why we use Stripe (for now) MapleDeploy keeps your data in Canada, but our payment processing goes through Stripe, a US company. Here's why, and what we offer as an alternative. URL: https://mapledeploy.ca/blog/why-we-use-stripe Date: 2026-03-13 MapleDeploy keeps your application data, databases, and server configurations on Canadian infrastructure. But our payment processing goes through Stripe, a US company. We tried to go fully Canadian. Here's why we couldn't, what it means for your data, and what we offer as an alternative. ## Why not a Canadian processor? We wanted to use [Helcim](https://www.helcim.com/), a Calgary-based payment processor with interchange-plus pricing and a genuinely good API. But Helcim's [acceptable use policy](https://legal.helcim.com/ca/acceptable-use-policy/) classifies "website hosting" as a prohibited business category when it's the sole service offering, and as a restricted category when it's part of a larger offering. MapleDeploy sells managed hosting, so we were cut off. This is a category-level policy, not specific to us. Payment processors use broad merchant category codes, and "hosting" falls into one that some processors restrict. It's the same categorization that applies to everything from shared web hosting to enterprise cloud platforms. But it creates an unfortunate catch-22 for a business built to keep Canadian data on Canadian infrastructure. We'd like to revisit this with Helcim as we build a track record. They do have a review process for restricted categories. ## Why Stripe So we went with Stripe. Here's what it gets us: - **[PCI Level 1 compliant](https://docs.stripe.com/security).** No card data touches our servers. Customers complete payment on [Stripe's hosted checkout page](https://docs.stripe.com/payments/checkout). - **Subscription lifecycle management.** Automated billing, dunning for failed payments, and self-service customer portal for card updates and invoice viewing. - **Extensive documentation and SDK.** Critical for a small team shipping quickly. - **Webhook coverage.** Every billing event we need is covered, from trial endings to payment failures to cancellations. ## What this means for your data Stripe is a US-headquartered company (with a [second headquarters in Dublin](https://stripe.com/newsroom/news/stripe-opens-new-dublin-hq)). Per [Stripe's privacy policy](https://stripe.com/privacy), Canadian personal data is transferred to data centers in the United States. This means payment data is subject to US jurisdiction, including potential access by US courts, law enforcement, or national security authorities. PIPEDA does not require personal data to remain in Canada. The [OPC's guidance on cross-border transfers](https://www.priv.gc.ca/en/privacy-topics/airports-and-borders/gl_dab_090127/) allows organizations to transfer personal information for processing, provided they ensure comparable protection and remain accountable for the data. It's a real tradeoff, and we'd rather be upfront about it than bury it in a privacy policy. Your application data, databases, and server configurations never leave Canada. Payment data is the only category that crosses the border, handled by a PCI Level 1 certified processor. ## We accept Interac e-Transfer For customers who prefer to keep payments within Canadian banking infrastructure, we accept Interac e-Transfer. Interac is a Canadian interbank network, and e-Transfer transactions are processed domestically between Canadian financial institutions. E-transfer payments are handled manually. You'll receive a monthly invoice and send payment directly. There's no automated billing or self-service portal for this option. Contact us at hello@mapledeploy.ca to arrange e-transfer billing. ## Looking ahead This isn't unique to us. Canadian payment processors exist, but the ones with mature APIs either classify hosting as restricted or don't offer the subscription lifecycle tooling we need. We didn't want to compromise on either, so we offer both: Stripe for automated billing, and Interac e-Transfer for customers who want payments to stay in Canada. We'd switch to a Canadian processor tomorrow if one would have us. If you know of one that serves managed hosting companies with mature subscription APIs, we're at hello@mapledeploy.ca. Until then, Stripe handles payments, and everything else stays in Canada. To be clear, we like Stripe. It's a genuinely great product, and their open source work (like [Markdoc](https://markdoc.dev/), the content authoring system behind this site) has been valuable to us directly. The issue isn't quality, it's jurisdiction. Our full list of service providers is on our [sub-processors page](/legal/subprocessors). {% cta-section title="Transparent about everything we use" %} Canadian infrastructure, open source foundation, honest about every tradeoff. 30-day free trial. {% /cta-section %} --- ## Canadian Data Sovereignty Canadian infrastructure for developers who want their data on Canadian soil. Built for PIPEDA compliance, outside US CLOUD Act, GDPR adequate. URL: https://mapledeploy.ca/canadian-hosting {% hero-section title="Canadian Hosting, Canadian Jurisdiction" %} Your application data stays in Canada, governed by Canadian law. No US parent company, no CLOUD Act exposure for your servers and databases. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% image-content-section title="Canadian infrastructure by default" src="dashboard-server-detail-active-zoom-card" width=1504 height=820 %} Dedicated VMs on LunaNode, a privately owned Canadian provider with data centers in Toronto. Each customer gets isolated infrastructure with their own Coolify instance, not shared containers on someone else's cluster. {% /image-content-section %} {% callout title="The problem with US platforms" %} Heroku, Railway, Render, Vercel, Fly.io: they're all US companies. Some offer non-US regions, including Canadian ones. That changes the geography, not the jurisdiction, and the **US CLOUD Act** still applies. US authorities can compel these companies to hand over data stored anywhere in the world, regardless of where your users are or what your privacy policy says. For Canadian businesses and developers who care about where their infrastructure lives, that's a problem. {% /callout %} {% feature-list-section title="What you get:" %} {% feature-list-item title="Canadian data residency" %} Canadian-owned servers in a Toronto data center, run from Canada on Canadian infrastructure {% /feature-list-item %} {% feature-list-item title="PIPEDA-ready infrastructure" %} Compliant-by-design architecture with Canadian data residency, TLS encryption in transit, and isolated customer environments {% /feature-list-item %} {% feature-list-item title="Outside US CLOUD Act" %} Your application data isn't subject to US legal demands {% /feature-list-item %} {% feature-list-item title="EU data transfer compliance" %} Canada's GDPR adequacy status means no standard contractual clauses or transfer impact assessments needed for EU data {% /feature-list-item %} {% feature-list-item title="Quebec Law 25 infrastructure" %} Canadian data residency simplifies cross-border transfer assessments under Quebec's privacy law {% /feature-list-item %} {% /feature-list-section %} {% feature-grid-section title="For your clients:" %} {% feature-card icon="globe" title="Clear answers" %} When they ask where their application data lives, you have a simple, honest answer: Canada. Servers, databases, and configurations are all on Canadian infrastructure. {% /feature-card %} {% feature-card icon="document" title="Documentation ready" %} Published [SLA](/legal/sla), [breach notification](/legal/breach-notification), [data residency attestation](/legal/data-residency), and [Canadian ownership verification](/legal/canadian-ownership). Additional documentation for procurement on request. {% /feature-card %} {% feature-card icon="lock" title="GDPR adequate" %} Canada has EU adequacy status, meaning the EU recognizes Canadian data protection as equivalent to GDPR standards. {% /feature-card %} {% /feature-grid-section %} {% checklist-section title="Same modern developer experience" subtitle="Data sovereignty doesn't mean giving up the tools you love. MapleDeploy gives you the same workflow you'd expect from any modern platform as a service." %} - Git push deploys with automatic SSL - One-click PostgreSQL, MySQL, Redis, MongoDB - Custom domains with automatic certificates - Environment variables and secrets management - PR preview environments with auto-cleanup - Real-time logs and deployment alerts (Discord, Telegram, email) - Automated weekly server snapshots with 30-day post-cancellation retention - Flat monthly pricing, all features included {% /checklist-section %} {% content-section title="Who this is for" %} {% audience title="Developers who prefer Canadian infrastructure" %} because you believe the jurisdiction of your tools matters, not because a regulation told you so. {% /audience %} {% audience title="Canadian businesses" %} who need to keep client data under Canadian jurisdiction. {% /audience %} {% audience title="Teams with residency commitments" %} whose customer or business data needs to stay under Canadian jurisdiction. {% /audience %} {% audience title="Agencies and consultancies" %} who want to offer clients a clear data sovereignty story. {% /audience %} {% audience title="Quebec-based businesses" %} who want Canadian data residency to simplify Law 25 cross-border transfer requirements. {% /audience %} {% /content-section %} {% content-section title="Built on open source" %} MapleDeploy runs on [Coolify](/open-source-stack), an open-source deployment platform you can audit on GitHub. The infrastructure runs on a privately owned Canadian provider with documented data center locations in Toronto. You can verify exactly what software handles your deployments, trace the ownership chain of your infrastructure provider, and document the precise physical location of your data. Whether you need that for a compliance audit or just want to know how your hosting works, it's all visible. No "trust us" required, just verifiable facts. {% /content-section %} {% cta-section title="Have questions about data residency?" hide-button=true %} We're happy to provide documentation for procurement, compliance audits, or client due diligence. {% button href="mailto:hello@mapledeploy.ca" variant="secondary" %} Contact us {% /button %} {% /cta-section %} {% cta-section title="Get started" button-text="Start free trial" %} All plans include Canadian data residency and full platform features. 30-day free trial, starting at $45 CAD/month. {% /cta-section %} --- ## The Canadian SaaS Stack A curated list of Canadian and non-US alternatives for building software on sovereign infrastructure. Hosting, email, payments, analytics, and more. URL: https://mapledeploy.ca/canadian-saas-stack {% hero-section title="The Canadian SaaS Stack" %} A curated guide to building software on Canadian and non-US infrastructure. Tools, services, and alternatives for developers who care about where their data lives. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Host on Canadian infrastructure {% /button %} {% /hero-section %} {% intro-section %} Building a credibly Canadian product means making deliberate choices about every service in your stack. This page lists Canadian-owned, Canadian-hosted, and non-US alternatives across the categories that matter most. Not everything has a perfect Canadian option. We're honest about the gaps. {% /intro-section %} {% content-section title="Browse by category" size="narrow" %} [Hosting and compute](#hosting) · [Deployment platforms](#deployment) · [Email](#email) · [Payments](#payments) · [CDN and DNS](#cdn-dns) · [Analytics](#analytics) · [Monitoring](#monitoring) · [Databases](#databases) · [Object storage](#object-storage) · [Authentication](#authentication) · [Version control and CI/CD](#version-control) {% /content-section %} {% callout title="Why this list exists" %} More procurement teams, compliance officers, and developers are asking the same question: is this service subject to the **US CLOUD Act**? If your hosting provider, email service, or database vendor is a US company, the answer is yes, regardless of where the data physically sits. This list helps you find alternatives. Some categories have strong Canadian options. Others don't. We've noted the tradeoffs so you can make informed decisions. For more context, see our guide on [building your SaaS on Canadian infrastructure](/blog/build-canadian-saas) and our explanation of the [CLOUD Act's impact on Canadian businesses](/blog/us-cloud-act-canadian-businesses). {% /callout %} {% feature-list-section id="hosting" title="Hosting and compute" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[LunaNode](https://www.lunanode.com/) (Toronto, Canadian-owned)" %} Canadian cloud provider with VMs and block storage. Toronto data center. Canadian-owned, no US parent company. This is what MapleDeploy runs on. {% /feature-list-item %} {% feature-list-item title="[Vexxhost](https://vexxhost.com/) (Montreal, Canadian-owned)" %} OpenStack public cloud from a Montreal company operating since 2005. Per-minute billing, public cloud egress at $0.10 per GB with free transfer on private platforms and Ceph, plus Kubernetes and bare metal. They also run regions in Santa Clara and Amsterdam, so pick the Montreal region for Canadian residency. {% /feature-list-item %} {% feature-list-item title="[Patrii Cloud](https://patrii.cloud/) (Montreal, Canadian-owned)" %} New Canadian sovereign cloud built on open source (OpenStack, Ceph). Montreal data center, VPS from $5.25 CAD/month with no bandwidth charges within Canada. Still early: the service is in beta and compliance certifications are planned, not yet in place. {% /feature-list-item %} {% feature-list-item title="[OVH Canada](https://www.ovhcloud.com/en-ca/) (Beauharnois QC, French parent)" %} Large European cloud provider with Canadian data centers in Beauharnois, Quebec (near Montreal) and the Toronto area. French-headquartered (OVHcloud), outside US jurisdiction. Good option for compute and dedicated servers. {% /feature-list-item %} {% feature-list-item title="[DigitalOcean](https://www.digitalocean.com/) (Toronto region, US-owned)" %} Has a Toronto region, but DigitalOcean is a US company subject to the CLOUD Act. Geography is Canadian, jurisdiction is not. See our [DigitalOcean comparison](/compare/digitalocean) for details. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="deployment" title="Deployment platforms" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="MapleDeploy (Toronto, Canadian-owned)" %} [Managed Coolify hosting](/open-source-stack) on dedicated Canadian infrastructure. Git push deploys, one-click databases, flat pricing starting at $45 CAD/month. [Canadian jurisdiction](/canadian-hosting), no US CLOUD Act exposure. {% /feature-list-item %} {% feature-list-item title="[Coolify](https://coolify.io/) (open source, self-hosted)" %} Open-source deployment platform you run on your own server. Pair with a Canadian VPS provider like LunaNode for Canadian data residency with full control. Free, but you manage the infrastructure. {% /feature-list-item %} {% feature-list-item title="[Dokploy](https://dokploy.com/) (open source, self-hosted)" %} The next most popular open-source deployment platform after Coolify, launched in 2024. Deploys applications, databases, and Docker Compose stacks, with Docker Swarm support for multi-node setups. Self-host it on a Canadian VPS for data residency. See our [Coolify vs Dokploy comparison](/blog/coolify-vs-dokploy) for a side-by-side breakdown. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="email" title="Email" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[Cakemail](https://www.cakemail.com/) (Montreal, Canadian-owned)" %} Transactional and marketing email based in Montreal. Canadian-owned. A genuine alternative to SendGrid and Mailgun for teams that need Canadian email infrastructure. {% /feature-list-item %} {% feature-list-item title="[Zedmail](https://zedmail.com/) (Ottawa, Canadian-owned)" %} Transactional email API with REST and SMTP support, hosted in Canada. No US parent company, no CLOUD Act exposure. Priced to compete with Amazon SES. {% /feature-list-item %} {% feature-list-item title="[MailChannels](https://www.mailchannels.com/) (Vancouver, Canadian-owned)" %} Transactional email API from a Vancouver company that has delivered email for hosting providers since 2004. REST and SMTP support, free up to 3,000 emails a month, then volume pricing. A high-volume Canadian sender. {% /feature-list-item %} {% feature-list-item title="[Mailbox.org](https://mailbox.org/) (Germany)" %} Business email hosting based in Germany. GDPR-compliant, outside US jurisdiction. Not Canadian, but a solid non-US alternative to Google Workspace and Microsoft 365 for business email. {% /feature-list-item %} {% feature-list-item title="The gap" %} High-volume transactional email is the thinnest category, but less so than it used to be. MailChannels handles serious volume, Zedmail is a newer Canadian entrant, and Cakemail covers most marketing and transactional use cases. Enterprise-volume senders should still evaluate deliverability and scale before committing. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="payments" title="Payments" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[Helcim](https://www.helcim.com/) (Calgary, Canadian-owned)" %} Canadian payment processor with interchange-plus pricing and a solid API. Works well for most SaaS businesses. Their acceptable use policy prohibits website hosting when it is the sole service offering, and restricts it when it is part of a larger offering, which is why MapleDeploy uses Stripe instead. Check their [acceptable use policy](https://legal.helcim.com/ca/acceptable-use-policy/) to confirm your business category fits. {% /feature-list-item %} {% feature-list-item title="[Stripe](https://stripe.com/) (US-owned)" %} The industry standard. Stripe is a US company, so payment data crosses the border. For businesses that Helcim supports, Helcim is the stronger sovereignty choice. We use Stripe because Helcim classifies hosting as restricted. See [why we use Stripe](/blog/why-we-use-stripe) for the full explanation. {% /feature-list-item %} {% feature-list-item title="The gap" %} Helcim is a credible Canadian option for most SaaS businesses, but no Canadian processor yet matches Stripe's subscription lifecycle tooling or global coverage. If your business category is supported, Helcim works. If not, Stripe is the practical fallback. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="cdn-dns" title="CDN and DNS" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[Bunny.net](https://bunny.net/) (Slovenia, EU-headquartered)" %} CDN and DNS provider based in Slovenia. GDPR-compliant, outside US jurisdiction. Edge delivery worldwide with European data governance. This is what MapleDeploy uses for DNS and CDN. {% /feature-list-item %} {% feature-list-item title="[CIRA Canadian Shield](https://www.cira.ca/en/canadian-shield/) (Canadian non-profit)" %} Privacy-respecting DNS operated by the Canadian Internet Registration Authority. No tracking, no data selling. Fully Canadian. Good for recursive DNS, not a CDN. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="analytics" title="Analytics" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[Umami](https://umami.is/) (open source, self-hosted)" %} Privacy-focused web analytics you host yourself. No cookies, GDPR-compliant by design. Deploy on your Canadian server for fully sovereign analytics. {% /feature-list-item %} {% feature-list-item title="[Plausible](https://plausible.io/) (EU-headquartered)" %} Lightweight, privacy-focused analytics based in the EU. Cloud-hosted on EU infrastructure or self-hostable. A clean alternative to Google Analytics. {% /feature-list-item %} {% feature-list-item title="[Fathom Analytics](https://usefathom.com/) (Canadian-founded)" %} Privacy-first analytics founded by Canadian developers. EU isolation processes and anonymizes EU visitors' personal data in the EU, but the anonymized analytics data is stored on US infrastructure. Good balance of simplicity and compliance. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="monitoring" title="Monitoring and observability" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[Better Stack](https://betterstack.com/) (Prague-based, US-incorporated)" %} Uptime monitoring, incident management, and log management. Team is based in Prague, but the company is incorporated in the US as Better Stack, Inc. Similar jurisdiction tradeoff to using any US entity. {% /feature-list-item %} {% feature-list-item title="[Hyperping](https://hyperping.com/) (Paris, French-owned)" %} Uptime monitoring, status pages, and on-call from a bootstrapped French company with EU data storage. Free tier with 20 monitors. Not Canadian, but a real non-US alternative to US-incorporated monitoring services. {% /feature-list-item %} {% feature-list-item title="[Grafana](https://grafana.com/) + [Prometheus](https://prometheus.io/) (open source, self-hosted)" %} Self-hosted monitoring stack. Run it on your Canadian server for fully sovereign observability. Requires ops investment to maintain. {% /feature-list-item %} {% feature-list-item title="The gap" %} There is no Canadian-owned monitoring SaaS comparable to Datadog or New Relic. Self-hosting with open-source tools or using EU-based services are the practical alternatives. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="databases" title="Databases" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="Self-managed on Canadian infrastructure" %} PostgreSQL, MySQL, Redis, and MongoDB are all open-source and can run on any Canadian server. MapleDeploy includes one-click database provisioning on your dedicated VM. {% /feature-list-item %} {% feature-list-item title="[OVHcloud](https://www.ovhcloud.com/en-ca/public-cloud/databases/) Managed Databases (Beauharnois QC, French parent)" %} Managed PostgreSQL, MySQL, and MongoDB in OVHcloud's Beauharnois, Quebec data center. French-headquartered, outside US jurisdiction. Pricier than self-managed, but the closest thing to a managed database service on Canadian soil without a US provider. {% /feature-list-item %} {% feature-list-item title="The gap" %} There is no Canadian-owned managed database service comparable to PlanetScale, Neon, or Supabase. OVHcloud's managed databases in Quebec are the closest non-US option. Otherwise, self-managed databases on Canadian compute remain the practical approach. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="object-storage" title="Object storage" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[eazyBackup e3](https://eazybackup.com/products/e3-object-storage/) (Saskatoon, Canadian-owned)" %} S3-compatible object storage from a Canadian company. Data stored in Ottawa in a facility registered under the Government of Canada Controlled Goods Program. This is what MapleDeploy uses for database backups. Works with Coolify's built-in S3 backup feature out of the box. {% /feature-list-item %} {% feature-list-item title="[OVHcloud](https://www.ovhcloud.com/en-ca/) Object Storage (Beauharnois QC, French parent)" %} S3-compatible object storage available in OVHcloud's Beauharnois, Quebec data center. French-headquartered, outside US jurisdiction. No egress fees, which is a significant advantage over AWS S3. {% /feature-list-item %} {% feature-list-item title="Self-hosted on Canadian infrastructure" %} Run S3-compatible storage on your own Canadian server. Pairs with any Canadian VPS provider for full data residency and control over your file storage. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="authentication" title="Authentication" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[Zitadel](https://zitadel.com/) (Swiss-founded, US-headquartered)" %} Open-source identity management built for multi-tenant SaaS. Founded in Switzerland, but the company is now US-headquartered and its managed cloud runs on Google Cloud. Supports OIDC, OAuth 2.0, SAML, MFA, and passkeys. Self-host it on Canadian infrastructure for sovereign auth. {% /feature-list-item %} {% feature-list-item title="[Keycloak](https://www.keycloak.org/) (open source, self-hosted)" %} Full-featured identity provider, a CNCF incubating project originally built by Red Hat. Supports OIDC, SAML, social login, MFA, and user federation. Self-host on a Canadian server for complete data residency. Operationally heavier than lighter alternatives, but very capable. {% /feature-list-item %} {% feature-list-item title="The gap" %} There is no Canadian-owned authentication service. Auth0, Clerk, and Cognito are all US-owned, and Zitadel is now US-headquartered too. Self-hosting Zitadel or Keycloak on Canadian infrastructure gives you data residency for user credentials and sessions. {% /feature-list-item %} {% /feature-list-section %} {% feature-list-section id="version-control" title="Version control and CI/CD" subtitle="Last reviewed: August 2026" %} {% feature-list-item title="[Forgejo](https://forgejo.org/) / [Gitea](https://about.gitea.com/) (open source, self-hosted)" %} Self-hosted Git forges you can run on Canadian infrastructure. MapleDeploy hosts its [Coolify fork on Forgejo](https://forgejo.mapledeploy.ca/rosslh/coolify). {% /feature-list-item %} {% feature-list-item title="[GitHub](https://github.com/) / [GitLab](https://about.gitlab.com/) (US-owned)" %} Both are US companies. GitHub is owned by Microsoft. GitLab offers self-managed options you can run on Canadian infrastructure, which gives you Canadian data residency for your repos and CI/CD. {% /feature-list-item %} {% /feature-list-section %} {% callout title="Honest about the gaps" %} A fully Canadian stack is not possible today. The practical approach is to be deliberate: use Canadian or EU services where strong options exist, and make informed tradeoffs where they don't. {% /callout %} {% image-content-section title="How MapleDeploy fits" src="dashboard-server-detail-active-zoom-card" width=1504 height=820 %} MapleDeploy is the deployment and hosting layer of this stack. We provision and manage [Coolify instances](/open-source-stack) on LunaNode in Toronto. Your apps, databases, and files live on a dedicated VM under Canadian jurisdiction. You still need to evaluate every other service in your stack. But if the foundation is Canadian, the rest of the decisions get easier. {% /image-content-section %} {% cta-section title="Start with the foundation" %} Canadian hosting with flat pricing. 30-day free trial, plans starting at $45 CAD/month. {% /cta-section %} --- ## MapleDeploy vs DigitalOcean - managed Canadian PaaS Compare MapleDeploy and DigitalOcean. A managed Canadian PaaS with git push deploys vs a raw VPS that requires DevOps expertise. URL: https://mapledeploy.ca/compare/digitalocean {% hero-section title="MapleDeploy vs DigitalOcean" %} Managed Coolify on Canadian infrastructure. Git push deploys without the DevOps. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} DigitalOcean offers two paths: raw Droplets (VPS) and App Platform (managed PaaS). Droplets give you full control but require DevOps expertise. App Platform handles deployments but bills per resource, with each container and database as a separate line item. As a Canadian DigitalOcean alternative, MapleDeploy sits in between: a [managed PaaS](/git-push-deploys) with dedicated resources that runs Coolify, supporting any Docker container or buildpack on Canadian infrastructure. {% /intro-section %} {% comparison-table-section title="Side by side" competitor="DigitalOcean" %} | Feature | DigitalOcean | MapleDeploy | | --- | --- | --- | | Jurisdiction and ownership | US company, CLOUD Act applies regardless of server location | Canadian-owned and operated ([SLA](/legal/sla), [compliance docs](/legal/sla)) | | Databases | Self-managed on Droplets; managed add-on ($15+ USD/mo) | One-click, included | | Deploys | Manual for Droplets; git deploys on App Platform | Git push deploys | | DevOps required | Yes for Droplets; no for App Platform | No | | SSL | Manual for Droplets; automatic on App Platform | Automatic | | Backups | Optional Droplet backups (20-30% of Droplet cost/mo, or usage-based from $0.01/GiB/mo); App Platform: deploy rollback, plus backups only on a paid managed database | Weekly full-server snapshots included, 30-day retention after cancellation | | Starting price | Droplets: [from $4 USD/mo](https://www.digitalocean.com/pricing) (512 MB, unmanaged, no deploys/SSL/databases); App Platform: from $5 USD/mo per container | From $45 CAD/mo (4 GB RAM dedicated VM, managed, git deploys + SSL + databases included) | | Type | Raw VPS or App Platform (limited PaaS) | Managed PaaS (we manage the server) | {% /comparison-table-section %} {% content-section title="Which DigitalOcean path fits you" %} If you want to learn Linux administration and have time for server management, a Droplet is cheaper and teaches you more. If you don't need Canadian jurisdiction and per-container billing suits you, App Platform is simpler. MapleDeploy fills the gap: managed deployment on dedicated Canadian infrastructure, with no framework restrictions and no per-resource billing. {% /content-section %} {% content-section title="The hidden cost of a $4 Droplet" %} A basic Droplet starts at $4 USD/mo for 512 MB of RAM. That price buys you a blank Linux server. Before you deploy anything, you need to configure a firewall, set up SSH keys, install a reverse proxy, provision SSL certificates with Let's Encrypt, write deployment scripts, and set up log rotation. That is a weekend of work if you've done it before. Longer if you haven't. Then there is ongoing maintenance. Security patches, unattended upgrades, certificate renewals, monitoring for downtime, and debugging when deploys fail at 2 AM. None of this is included in the $4/mo price. It is included in your time. Backups are extra too. Droplet backups cost 20-30% of your Droplet price per month, or a usage-based rate from $0.01 per GiB per month, and only capture the full disk image. App Platform itself has no backups: code lives in git and deploys can roll back, and only paid managed databases include backups. The $7/mo development database does not. MapleDeploy includes weekly full-server snapshots on every plan with 30-day retention after cancellation. A more realistic comparison: a 4 GB Droplet costs $24 USD/mo. Add managed PostgreSQL at $15.15 USD/mo. Add Droplet backups at roughly $5 USD/mo. That is $44 USD/mo before you have written a single deploy script or configured SSL. MapleDeploy's Starter plan at $45 CAD/mo (~$33 USD) includes all of that, managed. {% /content-section %} {% image-content-section title="Managed deploys, no scripts required" src="coolify-deploy-log-zoom-log" image-position="left" width=1664 height=865 %} Push your code and watch it deploy. Timestamped build logs, Docker image construction, and container rollouts happen automatically. No deploy scripts, no SSH sessions. {% /image-content-section %} {% content-section title="App Platform limitations" %} App Platform is DigitalOcean's managed PaaS. It handles deploys and SSL, similar to MapleDeploy. The tradeoff is flexibility and cost structure. App Platform charges per container. A basic 512 MB container costs $5 USD/mo. A 2 GB container costs $25 USD/mo. Each database is a separate line item at $7 USD/mo for a development instance or $15.15 USD/mo for managed PostgreSQL. Run a web app, a worker process, and a database, and you are looking at $17-65 USD/mo depending on container size and database type. Control is another constraint. App Platform builds from buildpacks or a Dockerfile, including multi-stage builds. What it does not give you is a server you control: no arbitrary background services, no databases you install yourself, and a fixed build environment. MapleDeploy runs [Coolify](/open-source-stack), which supports any Docker container, any Nixpacks-compatible project, and one-click deployments for dozens of services. The pricing model is the bigger issue. On App Platform, scaling means adding more containers at additional cost. On MapleDeploy, you have a dedicated VM with fixed resources. Deploy as many apps, workers, and databases as your VM can handle. One price, no surprises. {% /content-section %} {% cta-section title="Skip the server setup" %} Git push and you're live. Managed databases, automatic SSL, Canadian infrastructure. {% /cta-section %} --- ## MapleDeploy vs Fly.io - Canadian PaaS alternative Compare MapleDeploy and Fly.io. A managed Canadian PaaS with flat pricing vs US-incorporated infrastructure primitives with usage-based billing. URL: https://mapledeploy.ca/compare/fly {% hero-section title="MapleDeploy vs Fly.io" %} Canadian jurisdiction with flat pricing. Managed hosting instead of infrastructure primitives. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} Fly.io is a capable platform that runs containers across a global network of regions, including Toronto. It appeals to developers who want fine-grained control over where and how their applications run. As a Canadian alternative to Fly.io, MapleDeploy takes a different approach: a dedicated VM in Toronto with managed Coolify, flat pricing, and Canadian jurisdiction at every layer. This page covers the differences in jurisdiction, pricing, and operational complexity. {% /intro-section %} {% comparison-table-section title="Side by side" competitor="Fly.io" %} | Feature | Fly.io | MapleDeploy | | --- | --- | --- | | Architecture | Firecracker microVMs on shared hosts | Dedicated VM per customer | | Canadian region | Yes (Toronto yyz), but US jurisdiction | Yes, Canadian jurisdiction ([SLA](/legal/sla), [compliance docs](/legal/sla)) | | Databases | [Managed Postgres](https://fly.io/docs/mpg/) (from $38 USD/mo), unmanaged Postgres (self-supported), or bring your own | One-click, included | | IPv4 | [$2 USD/mo per address](https://fly.io/docs/about/pricing/) | Included | | Backups | Volume snapshots ($0.08/GB/mo after a free 10 GB) | Weekly full-server snapshots included, 30-day retention after cancellation | | Platform source | Proprietary | Open source (Coolify) | | Pricing | Usage-based (VMs + volumes + bandwidth + IPs, each billed separately) | From $45 CAD/mo (4 GB RAM dedicated VM, everything included) | | Operational complexity | High (infrastructure primitives, networking, scaling config) | Low (managed platform, git push deploys) | {% /comparison-table-section %} {% content-section title="Geography is not jurisdiction" %} Fly.io offers a Toronto region (yyz). Your application containers can run in Canada. Your data can sit on Canadian soil. That solves the latency question and the geography question. It does not solve the jurisdiction question. Fly.io is a [US-incorporated company](https://fly.io/about/). The [CLOUD Act](/blog/us-cloud-act-canadian-businesses) applies to Fly.io regardless of which region you deploy to. A US court can compel Fly.io to produce data stored in Toronto the same way it can compel data stored in Virginia. The server is in Canada. The legal framework governing access to that server is American. This is the same distinction that applies to [DigitalOcean's Toronto region](/compare/digitalocean). A Canadian data center does not create Canadian jurisdiction. Jurisdiction follows the company, not the server. MapleDeploy runs on LunaNode, a [Canadian-owned infrastructure provider](/canadian-hosting) in Toronto. No US parent company, no US incorporation, no CLOUD Act exposure. Canadian jurisdiction at every layer, not just Canadian geography. {% /content-section %} {% content-section title="Usage-based pricing is hard to predict" %} Fly.io bills separately for compute, storage, bandwidth, and IP addresses. Each dimension has its own rate, and the rates vary by region. A single application on Fly.io might look like this: a performance-1x VM with 2 GB RAM at roughly $32 USD/month, a 10 GB volume at $1.50/month, a dedicated IPv4 at $2/month, and bandwidth at $0.02/GB. That is around $36 USD/month before traffic. Add a second machine for redundancy, a managed Postgres database (from $38 USD/month), and moderate egress, and the bill climbs past $100 USD/month. The challenge is predictability. Traffic spikes increase bandwidth costs. Adding a new service means a new VM, a new volume, and a new IP address. Scaling up means larger VMs at higher hourly rates. Each change shows up on the bill. MapleDeploy charges a flat [$45 CAD/month](/#pricing) for a dedicated 4 GB RAM, 2 vCPU VM. Deploy as many applications, databases, and services as your resources allow. Bandwidth is included. IPv4 is included. SSL is included. The bill is the same every month. {% /content-section %} {% content-section title="Managed platform vs infrastructure primitives" %} Fly.io exposes infrastructure primitives: machines, volumes, networking, scaling rules, health checks, secrets, and inter-service communication. This gives experienced operators fine-grained control. It also means more configuration, more decisions, and more surface area for things to go wrong. Setting up a production application on Fly.io means writing a `fly.toml` configuration, managing machine sizes and counts, configuring volumes for persistent storage, setting up Postgres (Fly's [managed option](https://fly.io/docs/mpg/) starts at $38 USD/month, and the older unmanaged Postgres is now self-supported), wiring up private networking between services, and managing deployments through the Fly CLI. MapleDeploy runs [Coolify](/open-source-stack), which provides a web dashboard for managing all of this. Connect a git repo, push to deploy, provision databases with one click, configure environment variables through the UI. The operational overhead is significantly lower. You trade fine-grained infrastructure control for a managed experience that handles the server layer for you. For developers who enjoy managing infrastructure, Fly.io is a powerful tool. For teams that want to deploy and move on, a managed platform removes the distraction. {% /content-section %} {% content-section title="Migrating from Fly.io" %} Fly.io applications are typically Docker-based, which makes migration straightforward. Your Dockerfile works as-is on Coolify. If you are using Fly's Postgres, export with `pg_dump` and import into a PostgreSQL instance on your MapleDeploy VM. Configuration that lives in `fly.toml` (environment variables, health checks, scaling rules) maps to Coolify's application settings in the web dashboard. Fly's private networking between services is replaced by standard Docker networking on a single VM, which is simpler for most applications. The main adjustment is moving from a multi-region, multi-machine model to a single dedicated VM. For applications that genuinely need global distribution, this is a tradeoff. For applications serving Canadian and North American users from a single origin, a dedicated VM in Toronto is simpler and more predictable. {% /content-section %} {% cta-section title="Canadian jurisdiction, not just Canadian geography" %} One dedicated VM in Toronto. Flat pricing, managed platform, Canadian jurisdiction at every layer. {% /cta-section %} --- ## MapleDeploy vs Heroku - Canadian PaaS alternative Compare MapleDeploy and Heroku. A Canadian PaaS with data residency, dedicated resources, and flat pricing vs US-based containers with per-dyno billing. URL: https://mapledeploy.ca/compare/heroku {% hero-section title="MapleDeploy vs Heroku" %} Dedicated Canadian infrastructure with flat pricing. No dynos, no add-on fees, no US jurisdiction. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} Heroku pioneered the git push deploy workflow and remains a popular platform. But it's a Salesforce-owned, US-based service with no self-serve Canadian region, and pricing adds up quickly when you combine dynos, databases, and add-ons. MapleDeploy is the [Canadian PaaS](/) alternative to Heroku: a dedicated VM in Toronto with flat monthly pricing and the same git push experience. {% /intro-section %} {% comparison-table-section title="Side by side" competitor="Heroku" %} | Feature | Heroku | MapleDeploy | | --- | --- | --- | | Add-ons and databases | Marketplace with separate billing, [databases from $5 USD/mo](https://www.heroku.com/pricing) | Included, deploy what you need on your VM | | Architecture | Containers (dynos) on shared infrastructure | Dedicated VM per customer | | Data residency | US (Salesforce subsidiary); Canadian region only via Private Spaces (from $1,000 USD/mo) | Canada (Toronto) on every plan ([SLA](/legal/sla), [compliance docs](/legal/sla)) | | Backups | Database backups included with Postgres add-on (billed separately); no full-server snapshots | Weekly full-server snapshots included, 30-day retention after cancellation | | Platform source | Proprietary | Open source (Coolify) | | Pricing | Per dyno + add-ons ([from $7 USD/mo](https://www.heroku.com/pricing) for 512 MB always-on container, databases extra; $5 USD/mo Eco pool with sleep) | From $45 CAD/mo (4 GB RAM dedicated VM, databases + SSL + deploys included) | | Vendor lock-in | Heroku CLI and platform (Cloud Native Buildpacks and Docker deploys also supported) | Standard Docker and git workflows | {% /comparison-table-section %} {% content-section title="After Salesforce" %} Heroku pioneered the git push deploy workflow. For a long time, it was the fastest path from code to running app. That legacy is real and worth acknowledging. In 2010, Salesforce acquired Heroku. Development pace slowed through the 2010s. In November 2022, Heroku removed its free tier entirely, with no equivalent replacement. Thousands of developers who had built side projects, open-source tools, and demos on Heroku's free dynos had about three months to find alternatives. The platform continues to work, and it still has a large customer base. In February 2026, Heroku announced a move to a sustaining engineering model, prioritizing stability, security, and support over new features. Enterprise contracts are closed to new customers, though existing ones continue and can renew. Credit card customers, existing and new, keep the same pricing, billing, and service. For developers evaluating where to host new projects, that changes the calculus. The free tier is gone, pricing has moved up, new development is scoped to stability and security rather than new capabilities, and Heroku is a Salesforce subsidiary with US data jurisdiction. Many developers who left after 2022 landed on Railway, Render, or Fly. Those are US companies, so US jurisdiction follows your data regardless of where their servers sit. If [Canadian data residency](/canadian-hosting) matters to you, either for PIPEDA compliance or on principle, none of them solve the jurisdiction problem. MapleDeploy does. {% /content-section %} {% content-section title="The real cost of a production Heroku stack" %} Heroku's pricing looks simple until you build something real. A single web dyno at the Basic tier is $7 USD/month. Add a worker dyno for background jobs: another $7. A Standard-1X dyno for horizontal scaling and zero-downtime deploys: $25. Standard-2X for more memory: $50. You need a database, so Postgres Essential-0 is $5/month and Essential-1 is $9. Throw in a scheduler add-on and a logging service, and you're looking at $80-150 USD/month before you've added any redundancy or staging environments. A realistic production stack with a web dyno, worker, Standard-1X resources, Postgres, and a logging add-on sits comfortably at $100-200 USD/month. In Canadian dollars, that's $140-280 CAD at current exchange rates, and that's billed per resource with no ceiling. MapleDeploy's Starter plan is a flat $45 CAD/month. Deploy as many apps, databases, and background workers as your VM can handle. See [our pricing](/#pricing) for what each plan includes. {% /content-section %} {% content-section title="Migrating from Heroku" %} If you're considering a move, the practical path is straightforward. Your Heroku app already builds from a git repo. MapleDeploy deploys the same way: push to a branch, the platform builds and deploys. If you have a Dockerfile, it works as-is. If you're using Heroku buildpacks, Coolify's Nixpacks builder handles most frameworks automatically. The bigger shift is databases. Heroku Postgres add-ons are separate products with their own billing. On MapleDeploy, you provision PostgreSQL (or MySQL, Redis, MongoDB) directly on your VM. Use `pg_dump` to export from Heroku and `pg_restore` to import. Connection strings update in your environment variables. For other add-ons, Coolify's one-click service marketplace covers the most common needs: databases, Redis, monitoring, logging, and more. You deploy them alongside your app on the same VM. For anything not in the marketplace, you can run any Docker image directly. The model is different from Heroku's third-party add-on ecosystem, but the coverage is broader than you might expect. Our [getting started guide](/docs/deploy-your-first-app) walks through the full process from signup to a live app. {% /content-section %} {% image-content-section title="300+ one-click services" src="coolify-one-click-services-zoom-grid" image-position="left" width=1664 height=1094 %} WordPress, Supabase, Grafana, N8N, Ollama, and more. Deploy pre-configured services alongside your app with one click. No third-party add-ons, no separate billing. {% /image-content-section %} {% image-content-section title="Try it free for 30 days" src="dashboard-checkout-trial-zoom-summary" width=824 height=932 href="https://app.mapledeploy.ca/signup" %} Start with $0 due today. Your first charge comes after the trial. One flat price, no add-ons to calculate. {% /image-content-section %} {% cta-section title="Ready to switch?" %} Same git push deploys. Canadian infrastructure, flat pricing, dedicated resources, no add-on fees. {% /cta-section %} --- ## MapleDeploy vs Netlify - Canadian PaaS alternative Compare MapleDeploy and Netlify. A dedicated Canadian PaaS with flat pricing vs a US-based serverless platform with usage-based billing. URL: https://mapledeploy.ca/compare/netlify {% hero-section title="MapleDeploy vs Netlify" %} Dedicated Canadian hosting with flat pricing. One platform for your frontend, backend, and databases. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} Netlify is a popular platform built around a global edge CDN, with fast zero-config deploys for frontend frameworks. As a Canadian alternative to Netlify, MapleDeploy is a dedicated VM on Canadian infrastructure with flat monthly pricing. Both deploy websites. The differences are where your data lives, how you're billed, and what else you can run alongside your sites. {% /intro-section %} {% comparison-table-section title="Side by side" competitor="Netlify" %} | Feature | Netlify | MapleDeploy | | --- | --- | --- | | Architecture | Serverless/edge (no persistent server) | Dedicated VM per customer | | Data residency | US jurisdiction (Canadian function region on Pro and Enterprise) | Canadian jurisdiction ([SLA](/legal/sla), [compliance docs](/legal/sla)) | | Databases | Built-in Netlify Database (Neon-powered serverless Postgres) | One-click, self-hosted, deploy as many as you need | | Docker support | No | Yes | | Infrastructure | US regions by default (Canadian function region on Pro and Enterprise) | LunaNode (Toronto, Canada) | | Backups | No server snapshots (stateless platform; Netlify Database has its own recovery via Neon) | Weekly full-server snapshots included, 30-day retention after cancellation | | Platform source | Proprietary | Open source (Coolify) | | Pricing | Free tier available; paid plans from [$9 USD/mo](https://www.netlify.com/pricing/) (credit-based, serverless only, no Docker) | From $45 CAD/mo (4 GB RAM dedicated VM, Docker + databases + full-stack included) | | What you can deploy | Static sites, SSR frameworks, serverless functions, serverless Postgres, blob storage | Anything (Docker, databases, full-stack apps) | {% /comparison-table-section %} {% content-section title="Different architectures, different tradeoffs" %} Netlify is built around a global edge CDN. Connect a repo, get a site distributed worldwide in seconds. The tradeoff is usage-based billing that scales with your traffic, US infrastructure by default, and limited options when you need anything beyond frontend and serverless functions. MapleDeploy gives you a dedicated VM in Toronto. Connect a repo, push to your branch, and Coolify builds and deploys with automatic SSL. Static sites, frontends, backends, databases, and Docker containers all run on the same platform under one flat bill. For a Canadian audience served from Toronto, a single-region VM is fast. If you're serving a global audience and want edge caching, put Bunny.net or Cloudflare in front and you keep [Canadian data residency](/canadian-hosting) at the origin. For agencies and teams managing multiple projects, the economics diverge quickly. On Netlify, each site consumes credits for production deploys, compute, bandwidth, and requests. On MapleDeploy, one VM hosts all your projects under one flat price, with Canadian data residency included on every one. {% /content-section %} {% content-section title="Credit-based billing adds up" %} Netlify's free tier is generous for personal projects. Once you move to a team or start shipping client work, the credit system becomes harder to predict. For an agency managing ten client sites, the math compounds quickly. Each new project adds production deploys, compute, bandwidth, and web requests to the pool. When credits run out, Netlify pauses your projects until the next billing cycle, meaning sites go offline entirely. You can enable auto-recharge to buy additional credits automatically, but the costs add up. Neither outcome is ideal when a client is waiting on a fix. MapleDeploy charges a flat monthly price. One site or thirty, one deployment a month or fifty, the bill does not change. You can see the [full pricing breakdown](/#pricing) without a credit calculator. There are no overage fees. {% /content-section %} {% content-section title="Static sites, full-stack apps, everything in between" %} Static sites run great on MapleDeploy. Push a Next.js, Astro, SvelteKit, or plain HTML project and Coolify builds it, serves it, and handles SSL. One dedicated VM can host a dozen static sites alongside your backend APIs, databases, and background workers, all under one flat monthly price. Netlify's serverless model handles the frontend side well, but every unit of work has to fit inside an invocation. Synchronous functions have a 60-second execution limit, and scheduled and background functions cap out at 30 seconds and 15 minutes. Async Workloads covers queued, multi-step jobs, but a persistent worker or anything always-on is still outside Netlify's model. On MapleDeploy, those are just containers running on your VM. No extra providers, no extra bills. {% /content-section %} {% image-content-section title="300+ one-click services" src="coolify-one-click-services-zoom-grid" width=1664 height=1094 %} WordPress, Supabase, Grafana, Redis, and hundreds more are available as one-click services. Deploy databases, monitoring tools, and full applications alongside your frontend. No separate providers needed. {% /image-content-section %} {% cta-section title="One platform, flat pricing, Canadian infrastructure" %} Static sites, full-stack apps, databases. Deploy them all on one VM in Toronto. {% /cta-section %} --- ## MapleDeploy vs Railway - Canadian PaaS alternative Compare MapleDeploy and Railway. A Canadian PaaS with data residency, dedicated resources, and flat pricing vs US infrastructure with per-resource billing. URL: https://mapledeploy.ca/compare/railway {% hero-section title="MapleDeploy vs Railway" %} Canadian infrastructure with dedicated resources and flat pricing. Same developer experience, different jurisdiction. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} Railway is a solid developer platform. Fast deploys, easy Postgres provisioning, a clean workflow. As a Canadian alternative to Railway, MapleDeploy offers the same git push experience on top of Coolify, with a dedicated VM instead of shared containers. This page breaks down the differences in jurisdiction, resource isolation, and pricing. {% /intro-section %} {% comparison-table-section title="Side by side" competitor="Railway" %} | Feature | Railway | MapleDeploy | | --- | --- | --- | | Architecture | Containers on shared infrastructure | Dedicated VM per customer | | Data residency | US jurisdiction (EU/Asia available) | Canadian jurisdiction | | Databases | Included, resource usage metered | Included, deploy as many as you need | | Egress | Billed per GB | Included | | Infrastructure | US/EU/Asia (bare metal) | Canada (Toronto) | | PIPEDA compliance | No Canadian-specific infrastructure | Designed to support compliance ([SLA](/legal/sla), [breach notification](/legal/breach-notification)) | | Backups | Volume-level backups (manual or scheduled, daily/weekly/monthly options) | Weekly full-server snapshots included, 30-day retention after cancellation | | Platform source | Proprietary | Open source (Coolify) | | Pricing | Per-resource (free plan with $1/mo of usage credit; CPU, RAM, egress metered separately; a typical backend + database runs $40-80 USD/mo) | From $45 CAD/mo (4 GB RAM dedicated VM, all resources included, no metering) | {% /comparison-table-section %} {% content-section title="When Railway is the right choice" %} Railway is genuinely excellent for teams that want the fastest path from code to production and don't have data residency requirements. The developer experience is best-in-class. The UI is clean and thoughtful. Spinning up a service with a database takes minutes. If your project doesn't handle Canadian personal data, doesn't need to answer compliance questionnaires, and your team values a polished managed platform over dedicated infrastructure, Railway is a strong choice. Usage-based pricing also works well for low-traffic projects where a flat rate would be overkill. MapleDeploy makes more sense when you need Canadian jurisdiction, want predictable monthly costs regardless of traffic, or prefer dedicated resources over shared containers. Both platforms deploy from git. The difference is where your data lives and how you're billed for it. {% /content-section %} {% content-section title="The cost of per-resource billing" %} Railway offers a Free plan with $1 of monthly usage credit, enough for a small hobby app. The Hobby plan is $5 USD/month with $5 in credits, and the Pro plan is $20 USD/month with $20 in resource credits. Once you exceed your included credit, you pay $20/vCPU/month, $10/GB RAM/month, and $0.05/GB for outbound traffic. Those numbers sound modest in isolation. They add up quickly in practice. A typical backend app on Railway might use 0.5 vCPU and 512 MB RAM at idle, but spike to 1 vCPU and 1 GB RAM under load. Add a Postgres database at another 0.5 vCPU and 1 GB RAM, and a worker process at a similar footprint. You are now looking at 2 vCPU and 2.5 GB RAM sustained, before you account for traffic spikes. That puts you at $45-65 USD/month in a typical month, more if you ship a post that goes viral or run a batch job. The egress charge catches teams by surprise. $0.05/GB does not sound like much until your API is returning large payloads, your app serves image assets, or you move data between services. A moderate-traffic app transferring 100 GB/month adds $5 USD on top of resource usage. That is traffic you are already paying compute to generate. MapleDeploy starts at [$45 CAD/month](/#pricing) for a dedicated 4 GB RAM, 2 vCPU VM. Deploy a backend, a database, a worker, and a staging environment on the same VM. Egress is included. RAM and CPU are yours, not shared and not metered. The bill is the same whether you deploy one service or ten. {% /content-section %} {% content-section title="Dedicated resources vs shared containers" %} Railway runs your services as containers on shared infrastructure. Resources are metered because multiple tenants share the same underlying hardware. That works well for Railway, and it works well for most projects most of the time. But it means you are subject to the behavior of other workloads on the same machines. Noisy neighbor effects are real on shared container platforms. When another tenant saturates the host's disk I/O or memory bandwidth, your latency goes up. This is hard to debug because it does not appear in your application metrics. It looks like intermittent slowness with no clear cause. MapleDeploy gives each customer a [dedicated VM](/canadian-hosting). Your 4 GB of RAM is not shared with anyone else. Your 2 vCPUs are not competing for time. When you benchmark your app or profile a slow query, the numbers reflect your workload, not the aggregate of whoever else happens to be on the host. This also means predictable performance at deploy time. Container platforms can have cold start latency when spinning up new instances, particularly under traffic. A dedicated VM running Coolify keeps your services running continuously. No cold starts, no rescheduling delay, no slot availability waiting. For most hobby projects and early-stage products, the difference will not matter. For production APIs with SLAs, latency-sensitive workloads, or anything where you need consistent baseline performance, dedicated resources are the safer choice. See our [open-source stack](/open-source-stack) for how Coolify manages services on your VM. {% /content-section %} {% image-content-section title="Your resources, fully visible" src="coolify-server-metrics-zoom-charts" image-position="left" width=1664 height=920 %} Monitor CPU and memory usage in real time. With a dedicated VM, these metrics reflect your workload alone. No guessing about noisy neighbors or shared resource contention. {% /image-content-section %} {% image-content-section title="Try it free for 30 days" src="dashboard-checkout-trial-zoom-summary" width=824 height=932 href="https://app.mapledeploy.ca/signup" %} Start with $0 due today. Your first charge comes after the trial. One flat price, no resource metering to worry about. {% /image-content-section %} {% cta-section title="Ready to switch?" %} Same git push workflow you're used to. Canadian infrastructure, flat pricing, dedicated resources. {% /cta-section %} --- ## MapleDeploy vs Render - Canadian PaaS alternative Compare MapleDeploy and Render. A Canadian PaaS with data residency and flat pricing on a dedicated VM vs US-based per-service billing. URL: https://mapledeploy.ca/compare/render {% hero-section title="MapleDeploy vs Render" %} Canadian infrastructure with flat pricing. One dedicated VM instead of per-service billing. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} Render is a developer-friendly platform with a clean interface and straightforward deploys. But it is a US company with no Canadian region. Pricing is per-service: each web service, background worker, database, and cron job is a separate line item. MapleDeploy gives you a dedicated VM in Toronto with flat monthly pricing. The Canadian alternative to Render for teams that need jurisdiction, not just geography. {% /intro-section %} {% comparison-table-section title="Side by side" competitor="Render" %} | Feature | Render | MapleDeploy | | --- | --- | --- | | Architecture | Containers on shared infrastructure | Dedicated VM per customer | | Data residency | US company. Regions in US (Oregon, Ohio, Virginia), EU (Frankfurt), and Singapore. No Canadian region. | Canadian jurisdiction ([SLA](/legal/sla), [compliance docs](/legal/sla)) | | Databases | PostgreSQL from [$6 USD/mo](https://render.com/pricing), billed separately | One-click, included | | Key value (Redis-compatible) | [From $10 USD/mo](https://render.com/pricing), billed separately | One-click, included | | Backups | Point-in-time recovery on paid PostgreSQL plans (3 to 7 day window depending on workspace plan) | Weekly full-server snapshots included, plus a final snapshot kept 30 days after cancellation | | Cron jobs | [From $1 USD/mo](https://render.com/pricing), billed separately | Run as many as you need on your VM | | Platform source | Proprietary | Open source (Coolify) | | Pricing | Per service ([from $7 USD/mo](https://render.com/pricing) per web service, databases/key value/cron extra) | From $45 CAD/mo (4 GB RAM dedicated VM, all services included) | {% /comparison-table-section %} {% content-section title="Per-service billing adds up" %} Render's pricing is transparent per-service, but production stacks rarely consist of one service. A typical application needs a web service, a database, and often a background worker or cron job. A Starter web service is $7 USD/month. A Basic PostgreSQL database is $6 USD/month for compute, with storage billed separately at $0.30 USD per GB. Add a background worker at $7 and a cron job at $1, and you are at $21 USD/month for one small application. Scale to a Standard web service ($25), add a larger database and a key value cache ($10), and a single project clears $50 USD/month before storage and bandwidth. Run two or three projects and the costs compound quickly. Render's free tier has significant limitations. Free web services spin down after periods of inactivity and take time to cold-start when traffic returns. Free PostgreSQL databases expire after 30 days and are deleted. These constraints are fine for experimentation but not for production workloads. MapleDeploy starts at [$45 CAD/month](/#pricing) for a dedicated 4 GB RAM, 2 vCPU VM. Deploy a web service, a database, a worker, a Redis cache, and a staging environment on the same VM. No per-service fees, no cold starts, no database expiration. The bill is the same whether you run one service or ten. {% /content-section %} {% content-section title="The jurisdiction question" %} Render is a US company with regions in the [US, EU (Frankfurt), and Singapore](https://render.com/docs/regions). There is no Canadian region. Even if you deploy to a non-US region, Render is subject to the [CLOUD Act](/blog/us-cloud-act-canadian-businesses) as a US-incorporated company, which means US courts can compel access to your data regardless of your own privacy policies. For side projects and internal tools, this is unlikely to matter. For Canadian businesses running client portals, agency workflows, B2B SaaS, or any project where a client might ask "where does our data live," the answer matters. "US company, US infrastructure" is a factual answer that may not work for your use case. MapleDeploy runs on [Canadian-owned infrastructure](/canadian-hosting) in Toronto. No US parent company, no CLOUD Act exposure for your application data. Canadian jurisdiction at every layer. {% /content-section %} {% content-section title="Migrating from Render" %} Render deploys from Docker or git repos, so migration is straightforward. If your app builds on Render, it builds on Coolify. Dockerfiles work as-is. Framework auto-detection on Coolify handles most projects without configuration changes. For databases, export with `pg_dump` (PostgreSQL) or the equivalent for your database engine, and import into a database running on your MapleDeploy VM. Connection strings update in your environment variables. Redis data can be migrated with `redis-cli --rdb` or by starting fresh if the cache is ephemeral. Render's environment groups and service linking have equivalents in Coolify's environment variable management. The configuration is explicit rather than automatic, which means a few extra minutes of setup but full visibility into every connection string. {% /content-section %} {% image-content-section title="Try it free for 30 days" src="dashboard-checkout-trial-zoom-summary" width=824 height=932 href="https://app.mapledeploy.ca/signup" %} Start with $0 due today. Your first charge comes after the trial. One flat price, no per-service billing to track. {% /image-content-section %} {% cta-section title="Ready to switch?" %} Same git push deploys. Canadian infrastructure, flat pricing, dedicated resources, no per-service fees. {% /cta-section %} --- ## MapleDeploy vs Vercel - Canadian PaaS alternative Compare MapleDeploy and Vercel. A full-stack Canadian PaaS with flat pricing vs a US serverless platform built for frontend frameworks. URL: https://mapledeploy.ca/compare/vercel {% hero-section title="MapleDeploy vs Vercel" %} Dedicated Canadian hosting with flat pricing. From Next.js sites to full-stack apps, one platform. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} Vercel is a leading deployment platform for frontend frameworks, especially Next.js. It's optimized for edge delivery and serverless functions. As a Canadian alternative to Vercel, MapleDeploy is a dedicated VM on Canadian infrastructure with flat monthly pricing. Both deploy websites and Next.js applications. The differences are jurisdiction, pricing model, and what else you can run on the same platform. {% /intro-section %} {% comparison-table-section title="Side by side" competitor="Vercel" %} | Feature | Vercel | MapleDeploy | | --- | --- | --- | | Bandwidth | Metered beyond plan limits | Included | | Best for | Stateless web apps, frontend frameworks, and HTTP services | Any workload (web apps, APIs, databases) | | Data jurisdiction and ownership | US company, US law (CLOUD Act applies). [Montreal region](https://vercel.com/docs/regions) available for function execution, but jurisdiction follows the company. | Canadian-owned and operated ([SLA](/legal/sla), [compliance docs](/legal/sla)) | | Databases | Add-on services, usage-billed | One-click, included | | Deploys | Git push (frontend, functions, and Dockerfile containers) | Git push (any Dockerfile or buildpack) | | Backups | No server backups (serverless, stateless). Database backups depend on marketplace provider. | Weekly full-server snapshots included, 30-day retention after cancellation | | Platform source | Proprietary | Open source (Coolify) | | Pricing | [$20 USD/mo base](https://vercel.com/pricing) + $20/additional seat + usage fees (databases and storage are usage-billed add-ons) | From $45 CAD/mo (4 GB RAM dedicated VM, databases + full-stack included, no per-seat fees) | | Type | Serverless platform (stateless compute) | Managed PaaS (full-stack) | {% /comparison-table-section %} {% content-section title="The serverless tradeoff" %} Vercel is genuinely excellent at what it's designed for: deploying static sites and Next.js apps with a global edge network and zero server management. If your entire stack lives in serverless functions and you have no persistent state, the model works well. The friction shows up when your application grows. Vercel has filled in much of what serverless used to rule out. Cron jobs, queues, durable workflows, and WebSockets in public beta all run natively now, and a Dockerfile deploys on Fluid compute alongside the functions. What stays true is the state itself. Vercel's own docs put it plainly: you can't run your own Postgres or Redis container with local disk, so persistent state lives in a backing service you attach. Cold starts are much reduced with Fluid compute and function pre-warming, though they can still occur during traffic spikes or for infrequently-used routes. Vercel's caching and routing layer is tuned to its own infrastructure, so moving to another host means re-tuning that layer. MapleDeploy runs a standard server process. Your Next.js app, a background job worker, a PostgreSQL database, a Redis cache, they all run on the same VM under your control, deployed via Docker or buildpacks. There are no function timeouts, no cold starts, and no proprietary abstractions to unwind if your needs change. The [open-source Coolify layer](/open-source-stack) is the only platform-specific interface, and Coolify itself is portable. The honest summary: if you need a global edge network and your workload is purely frontend-plus-serverless, Vercel is hard to beat. If you need full-stack flexibility, Canadian data residency, or predictable flat pricing as your team and project count grow, MapleDeploy is worth the comparison. {% /content-section %} {% content-section title="Running Next.js outside Vercel" %} A common concern: does Next.js work well outside Vercel? Yes. Next.js is an open-source framework that runs anywhere Node.js runs. Vercel adds a global edge network, its own caching layer, and an image optimization CDN. The framework features behind them, ISR, middleware, and next/image, run self-hosted too. On MapleDeploy, Next.js deploys via git push with automatic detection. Server-side rendering, API routes, and dynamic pages all work. You get a dedicated server in Toronto with predictable performance and no per-request billing. Vercel adds a global edge network and proprietary caching on top, but the core framework runs the same. The tradeoff: Vercel's edge network distributes static content across global points of presence, which helps if your users are spread worldwide. MapleDeploy serves from Toronto, which means strong performance across Canada and the US northeast. If you need global edge caching, adding a CDN like Bunny.net or Cloudflare in front of your MapleDeploy server closes that gap, while keeping your origin and data in Canada. {% /content-section %} {% image-content-section title="See every build step" src="coolify-deploy-log-zoom-log" image-position="left" width=1664 height=865 %} Real-time deployment logs show exactly what's happening. Docker image builds, container rollouts, and timestamped steps. No black-box deploys. {% /image-content-section %} {% content-section title="Agencies and multi-project teams" %} If you're managing multiple Next.js sites or client projects, the pricing models diverge fast. On Vercel, bandwidth and serverless function usage are metered across all projects and billed beyond included allocations, and each additional deploying team member is $20 USD/month. Consider a small agency with five developers and twenty client sites. At Vercel Pro, that's $20 USD platform fee plus $80 USD for the four additional deploying seats, so $100 USD/month. That includes 1 TB of bandwidth and a $20 usage credit, but function invocations and storage for each project add up from there. In CAD at typical exchange rates, you're looking at $140 or more each month just in platform fees. On MapleDeploy, the same setup costs $95 CAD/month on the Pro plan. All five developers deploy freely, no per-seat charge. All twenty sites share the VM. A shared PostgreSQL database is one click away. The bill is the same whether you have two developers or ten, and whether you're hosting three client projects or thirty. See our [plans and pricing](/#pricing) for the full specs breakdown. {% /content-section %} {% image-content-section title="Choose your plan" src="dashboard-create-server-zoom-plans" width=1404 height=1100 href="https://app.mapledeploy.ca/signup" %} Pick a dedicated Canadian VM, provisioned in minutes. One flat price covers your frontend, backend, and databases. No per-seat charges, no bandwidth metering. {% /image-content-section %} {% cta-section title="One platform, flat pricing, Canadian infrastructure" %} Next.js, backends, databases. Deploy them all on one VM in Toronto. {% /cta-section %} --- ## Account recovery Recover dashboard access after a forgotten password, lost passkey, lost authenticator app, or inaccessible email inbox. URL: https://mapledeploy.ca/docs/account-recovery This guide covers account recovery for the MapleDeploy dashboard. If you can still sign in, fix the issue from **Settings** > **Account** where possible. If you cannot sign in, use the recovery path below. ## Reset a forgotten password 1. Go to [app.mapledeploy.ca/forgot-password](https://app.mapledeploy.ca/forgot-password). 2. Enter your account email address. 3. Check your inbox for a password reset email. 4. Open the reset link. 5. Enter and confirm your new password. 6. Return to the sign-in page and sign in with the new password. For privacy, the forgot password page shows the same confirmation whether or not the email address belongs to an account. Password reset links expire after 1 hour. Resetting your password signs out existing dashboard sessions. ## Lost authenticator app If you still have a recovery code, use **Use a recovery code** on the two-factor challenge screen. If you are already signed in on another browser or device and still have your authenticator app, regenerate recovery codes from **Settings** > **Account** > **Two-factor authentication**, then store the new codes. If you lost both your authenticator app and your recovery codes, contact [hello@mapledeploy.ca](mailto:hello@mapledeploy.ca). We will verify account ownership before resetting two-factor authentication. ## Lost passkey If you still have another sign-in method, sign in with that method and revoke the lost passkey from **Settings** > **Account** > **Passkeys**. If the lost passkey was your only sign-in method, try password reset or a connected social provider. If neither is available, contact [hello@mapledeploy.ca](mailto:hello@mapledeploy.ca). ## Lost access to your email inbox If you are still signed in, change your email from **Settings** > **Account** > **Email** and confirm the new address. If you are signed out and cannot access your email inbox, contact [hello@mapledeploy.ca](mailto:hello@mapledeploy.ca). We will need to verify account ownership before changing the email address. ## Related docs - [Dashboard authentication](/docs/authentication) - [Organizations](/docs/organizations) --- ## Dashboard authentication How to sign in to the MapleDeploy dashboard with passwords, social sign-in, passkeys, and two-factor authentication. URL: https://mapledeploy.ca/docs/authentication This guide covers sign-in for the MapleDeploy dashboard at `app.mapledeploy.ca`. Coolify sign-in, Git provider sign-in inside Coolify, and authentication for your own applications are separate systems. ## Sign-in methods Your MapleDeploy account can have more than one sign-in method. - **Email and password:** Use the email address and password on your MapleDeploy account. You can change or set your password from **Settings** > **Security** > **Password**. - **Social sign-in:** Social buttons appear only for providers currently enabled on MapleDeploy. MapleDeploy does not automatically link a social provider just because it reports the same email address. Sign in first, then connect a provider from **Settings** > **Security** > **Connected accounts**. - **Passkeys:** Passkeys let you sign in with Touch ID, Face ID, Windows Hello, browser-synced passkeys, or compatible security keys. - **Two-factor authentication:** Two-factor authentication adds an authenticator app after password sign-in. If your account has two-factor authentication enabled, passkey sign-in completes sign-in on its own. Password sign-in still requires your authenticator code. ## Sign in Use one of the sign-in methods available on your account: - Enter your email and password. - Select **Sign in with a passkey** if you have registered a passkey. - Use a social sign-in button if the provider is shown and connected to your account. If password sign-in asks for a second factor, enter your authenticator code or use a saved recovery code. ## Create an account 1. Go to [app.mapledeploy.ca/signup](https://app.mapledeploy.ca/signup). 2. Enter your name, email, password, and optional organization name. 3. Accept the terms. 4. Submit the form. 5. Return to the sign-in page and sign in with your new account. If a social sign-in button is shown, you can use it to create or sign in to an account with that provider instead. If you are accepting an organization invitation, use the email address from the invitation. The invitation flow returns you to the invitation after signup or sign-in. ## Change your password 1. Open **Settings** > **Security** > **Password**. 2. Enter your current password. 3. Enter and confirm the new password. 4. Save the change. If your account does not currently have a password, the dashboard shows **Set a password** instead. ## Add a passkey To add a passkey: 1. Sign in to the dashboard. 2. Open **Settings** > **Security** > **Passkeys**. 3. Enter a name for the passkey. 4. Enter your current password and, if two-factor authentication is enabled, your authenticator code. 5. Confirm the action. 6. Complete the browser or device passkey prompt. After a passkey is added, you can use **Sign in with a passkey** on the sign-in page. To remove a passkey, open **Settings** > **Security** > **Passkeys**, choose **Revoke**, enter the required verification details, and confirm the action. ## Enable two-factor authentication To enable two-factor authentication: 1. Sign in to the dashboard. 2. Open **Settings** > **Security** > **Two-factor authentication**. 3. Enter your current password. 4. Scan the QR code in an authenticator app, or enter the manual key. 5. Save the recovery codes shown during setup. 6. Enter the code from your authenticator app to finish setup. Recovery codes are shown only during setup or regeneration. Each code works once. Store them somewhere you can reach if you lose your authenticator device. ## Manage social sign-in Open **Settings** > **Security** > **Connected accounts**. To connect a provider, choose the provider, enter your current password and any required authenticator code, then complete the provider sign-in flow. The provider email must match your MapleDeploy account email. To disconnect a provider, choose **Disconnect** for that provider, enter the required verification details, and confirm the action. MapleDeploy blocks disconnecting the only remaining sign-in method. ## Change your email address 1. Open **Settings** > **Account** > **Email**. 2. Enter the new email address and your current password. 3. Check the new email inbox for the verification email. 4. Open the verification link while signed in to the dashboard. Your email address is not changed until the verification link is confirmed. ## Sign out Use **Sign out** from the dashboard menu. This ends the current dashboard session in the browser. If you signed in on another browser or device, sign out there too. Changing or resetting your password revokes other active sessions. ## Account recovery For forgotten passwords, lost passkeys, lost authenticator apps, or lost inbox access, see [Account recovery](/docs/account-recovery). --- ## Backup guide Protect your data with automated backups. Set up database backups using Coolify's built-in S3 backup feature with step-by-step instructions. URL: https://mapledeploy.ca/docs/backups **Your data is your responsibility.** MapleDeploy snapshots are a safety net, not a replacement for your own database backups. For production databases, set up Coolify's S3 backup feature. ## Setting up Coolify database backups Coolify has built-in support for automated database backups to any S3-compatible storage. It supports PostgreSQL, MySQL, MariaDB, and MongoDB. This is the recommended way to protect your databases. ### Step 1: Choose an S3 provider Any S3-compatible storage will work, including [AWS S3](https://aws.amazon.com/s3/), [eazyBackup e3](https://e3.eazybackup.com/) (Canadian), or whichever provider you prefer. ### Step 2: Add S3 storage in Coolify In Coolify, go to **Settings** > **S3 Storages** and select **Add Storage**. Enter the S3 details from your storage provider: - Endpoint - Access key - Secret key - Bucket name Test the connection before you continue. ### Step 3: Configure database backup Open your database resource in Coolify, then open **Backups**. Set: - The S3 storage destination. - A backup schedule. Use daily backups for production databases. - A retention count, such as the last 14 backups. Enable the backup after those settings are saved. ### Step 4: Test your backup After setting up, trigger a manual backup and verify the file appears in your S3 bucket, the file size is reasonable (not empty), and you can download and open it. ## Restoring from backup Use Coolify's import or restore flow when available. If you restore manually, PostgreSQL custom-format backups use `pg_restore`, MySQL or MariaDB use `mysql` or `mariadb`, and MongoDB uses `mongorestore`. To restore a MapleDeploy VM snapshot after active-server corruption or post-cancellation recovery, contact [hello@mapledeploy.ca](mailto:hello@mapledeploy.ca). We can restore from the latest available recovery snapshot: the latest weekly snapshot for active-server disaster recovery, or the pre-deletion snapshot retained for 30 days after cancellation. ## MapleDeploy snapshots MapleDeploy takes weekly snapshots of your entire VM, including the OS, Coolify, Docker containers, volumes, and databases. We also take a snapshot before any VM termination. After cancellation, snapshots are kept for 30 days on our Canadian infrastructure in Toronto. Only MapleDeploy staff can access them, and only to fulfill a restore request from the verified account holder. Snapshots use our infrastructure provider's volume snapshot system. After 30 days, they are permanently deleted. Snapshots are point-in-time copies and can be up to 7 days old. They are intended for disaster recovery, not granular database restores. ## Best practices Use these defaults for production databases: - Back up at least daily. - Keep at least 14 to 30 days of backups. - Store backups in a separate S3 bucket, away from your production server. - Test restores periodically, not just backup creation. - Check Coolify's backup logs so failures do not go unnoticed. --- ## Coolify team access Set up, reset, and remove Coolify access for organization members so teammates can deploy on the right MapleDeploy server. URL: https://mapledeploy.ca/docs/coolify-access Your MapleDeploy dashboard account and your Coolify login are separate. Organization membership controls what you can see and manage in the MapleDeploy dashboard. Coolify access controls what you can do inside a specific Coolify server. ## How access works On servers with Coolify access available from the MapleDeploy dashboard, each organization member can set up their own Coolify login from the server details page. Dashboard-created Coolify logins are Coolify team admins on that server. This means: - Owners and admins can manage the server in MapleDeploy and inside Coolify. - Members are read-oriented in MapleDeploy, but can deploy apps and manage resources inside Coolify after setting up Coolify access. ## Set up or reset your Coolify login 1. Sign in to the MapleDeploy dashboard. 2. Open the server. 3. Use **Coolify access** to choose a Coolify password. 4. Confirm the action with your dashboard account. The same form resets your Coolify password later. MapleDeploy sends the password to your Coolify instance and does not store it. If you do not see **Coolify access** on your server details page, use your existing Coolify login or contact [hello@mapledeploy.ca](mailto:hello@mapledeploy.ca). ## Claim the admin account on an older server Some older servers may already have a Coolify admin account. Organization owners can use **Claim admin account** on the server details page to connect that admin account to their MapleDeploy account and set a new password. ## Remove a teammate When a member is removed from the organization, MapleDeploy removes their dashboard access to the organization. On servers with Coolify access available from the MapleDeploy dashboard, MapleDeploy also blocks their dashboard-created Coolify login. Coolify users created directly inside Coolify are not managed by MapleDeploy. Removing access does not rotate credentials the teammate may have copied while they had access. For sensitive offboarding, rotate deploy keys, SSH keys, Git provider tokens, registry tokens, webhooks, database passwords, and application environment secrets. ## Related docs - [Organizations](/docs/organizations) - [Dashboard authentication](/docs/authentication) --- ## Create your server Create a MapleDeploy account, choose a plan, follow provisioning, and open your managed Coolify server when it is ready. URL: https://mapledeploy.ca/docs/create-your-server This guide covers the first MapleDeploy step: creating your account and server. Each server is a dedicated VM in Toronto with its own Coolify instance. Once provisioning finishes, you can deploy applications from Coolify. ## Step 1: Create your account Go to the [signup page](https://app.mapledeploy.ca/signup) and create an account. If you already have an account, sign in and go to the dashboard. ## Step 2: Create a server From the dashboard, select **Create server**. Choose a subdomain. This becomes your MapleDeploy server address, such as `your-name.mapledeploy.ca`, and is used for your Coolify dashboard URL. Then choose a plan. Starter and Pro include a 30-day free trial, so you can deploy a real project before the first charge. {% content-image src="dashboard-create-server-zoom-plans" caption="Choose the plan that matches the resources your apps need." width=1404 height=1100 /%} ## Step 3: Wait for provisioning After checkout, MapleDeploy creates your VM, installs Coolify, prepares SSL, and connects the server to your dashboard. Provisioning usually takes about 10 minutes. The dashboard shows progress while the server is being prepared. {% content-image src="dashboard-provisioning-progress-zoom-card" caption="The provisioning checklist updates as your server is prepared." width=704 height=740 /%} You will receive an email when the server is ready. ## Step 4: Open Coolify When provisioning completes, open the server details page and select the Coolify dashboard link. {% content-image src="dashboard-server-detail-active-zoom-card" caption="Your server details page links to your Coolify dashboard." width=1504 height=820 /%} Coolify is where you deploy applications, create databases, configure domains, and manage environment variables. ## Next step Continue with [Deploy your first app](/docs/deploy-your-first-app). --- ## Custom domains Point your own domain at a Coolify application on MapleDeploy, configure DNS records, and let Coolify issue SSL certificates. URL: https://mapledeploy.ca/docs/custom-domains Your app works on its temporary Coolify URL as soon as it deploys. When you are ready to use your own domain, configure DNS and add the domain in Coolify. ## What you will need - A deployed Coolify application. - A domain name you control. - Access to your domain registrar or DNS provider. - Your MapleDeploy server IP address. You can find the server IP in the MapleDeploy dashboard on the server details page, or in Coolify under **Settings** > **Server**. ## Step 1: Add DNS records At your DNS provider, create A records that point to your server IP. | Type | Name | Value | | ---- | ---- | ----- | | A | `example.com` | Your server IP | | A | `www` | Your server IP | DNS changes often work within 10 to 30 minutes, but some providers can take longer. ## Step 2: Add the domain in Coolify Open your application in Coolify. In the **General** settings, find **Domains**. Enter each domain as a full URL, separated by commas: ```text https://example.com,https://www.example.com ``` {% content-image src="coolify-app-config-zoom-general-config" caption="Enter custom domains in Coolify using the full URL format." width=1664 height=518 /%} Save the change and redeploy the application. ## Step 3: Verify SSL After the deploy finishes, visit your domain in a browser. Coolify issues an SSL certificate after DNS points to your server. If the certificate is not ready yet, wait a few minutes and try again. Once the domain is working, the **Links** menu will show your production URLs. {% content-image src="coolify-links-dropdown-zoom-panel" caption="The Links menu shows your custom domain after it is configured." width=516 height=227 /%} ## Troubleshooting **The domain still points somewhere else:** Check the A record at your DNS provider and confirm it points to your MapleDeploy server IP. **SSL is not issued yet:** DNS must resolve to your server before the certificate can be issued. If you recently changed DNS, wait a few minutes and redeploy. **The app returns 502:** The domain is reaching the server, but the application is not responding on the expected port. Confirm **Ports Exposes** matches the port your application listens on. --- ## Deploy your first app Deploy a Git-backed application on MapleDeploy with Coolify. Connect your repository, configure the build, deploy, and verify the result. URL: https://mapledeploy.ca/docs/deploy-your-first-app This guide starts after your MapleDeploy server is ready. If you have not created a server yet, start with [Create your server](/docs/create-your-server). By the end, you will have an application running on your MapleDeploy server using Coolify. ## What you will need - A Git repository hosted on GitHub, GitLab, Bitbucket, Gitea, or another Git host. - A Dockerfile in your repository, or a project that Nixpacks can detect. - The port your application listens on, such as `3000`, `5000`, or `8080`. GitHub has the deepest Coolify integration. For other Git providers, public repositories can use **Public Repository** and private repositories use deploy keys. ## Step 1: Open Coolify Sign in to the [MapleDeploy dashboard](https://app.mapledeploy.ca/login), open your server, and select the Coolify dashboard link. {% content-image src="dashboard-server-detail-active-zoom-card" caption="Open Coolify from your server details page." width=1504 height=820 /%} ## Step 2: Connect your Git provider If your code is on GitHub, start there. In Coolify, go to **Sources** and add a GitHub App. GitHub will ask which repositories the app can access. Once connected, Coolify can pull from those repositories and create webhooks for automatic deploys when you push to the selected branch. {% content-image src="coolify-sources-zoom-content" caption="Connected Git sources are reused across future applications." width=407 height=128 /%} For GitLab, Bitbucket, Gitea, and other Git providers, public repositories can use **Public Repository**. For private repositories, choose **Private Repository (Deploy Key)**. Coolify generates a public deploy key. Add that key to your repository settings with read access. For GitLab, Bitbucket, and Gitea, use the **Manual Git Webhooks** section in Coolify, set the matching webhook secret, and configure push events in your Git provider. For other Git providers, use the auth-required deploy webhook with a Coolify API token through your provider's workflow or webhook system. ## Step 3: Create the application In Coolify, create a project. Projects group related resources. Inside the project, choose **Add New Resource**, then select the repository type: - **Public Repository** for a public repo. - **Private Repository (GitHub App)** for a repo connected through GitHub. - **Private Repository (Deploy Key)** for a private repo from any Git provider. Select the repository and branch to continue. {% content-image src="coolify-add-resource-zoom-types" caption="Choose the repository type that matches your Git setup." width=1664 height=598 /%} ## Step 4: Configure the build Coolify needs to know how to build your app and which port it should route traffic to. ### Build pack If your repository has a Dockerfile, select **Dockerfile**. This is the most predictable option because your repository controls the build. If the Dockerfile is not in the repository root, set **Dockerfile Location** to its path from the app base directory, such as `/docker/Dockerfile`. If you do not have a Dockerfile, select **Nixpacks**. Nixpacks auto-detects common project types. For monorepos or unusual builds, use a Dockerfile. ### Exposed port In the **Network** section, set **Ports Exposes** to the port your app listens on: - Node.js Express or Next.js: `3000` - Python Flask: `5000` - Go HTTP server: `8080` This must match your app exactly. If the port is wrong, the container may start but the app will not be reachable. {% content-image src="coolify-app-config-zoom-network" caption="Set Ports Exposes to the port your application listens on." width=1664 height=224 /%} ## Step 5: Deploy Select **Deploy**. Coolify pulls your code, builds the image, starts the container, and shows logs while it works. When deployment finishes, open the **Links** menu at the top of the application page. Coolify gives you a temporary URL that works immediately. {% content-image src="coolify-links-temp-zoom-panel" caption="The temporary URL is useful for checking the app before adding a custom domain." width=612 height=171 /%} ## Step 6: Verify the app Open the temporary URL. If the app loads, your deployment is working. If it does not load, check the most common causes first: - **Build errors:** Read the build logs and fix missing dependencies or failed commands. - **Port mismatch:** Set **Ports Exposes** to the exact port your app binds to. - **Missing environment variables:** Add required variables in **Environment Variables**, then redeploy. - **Localhost binding:** Bind the app to `0.0.0.0`, not only `127.0.0.1` or `localhost`. ## Next steps For a production URL, follow [Custom domains](/docs/custom-domains). For databases, set up backups before you store important data. See the [backup guide](/docs/backups). --- ## Docs Guides for getting the most out of your MapleDeploy server. Set up backups, configure deployments, and manage your Canadian hosting environment. URL: https://mapledeploy.ca/docs --- ## Organizations How MapleDeploy organizations handle roles, invitations, billing access, trials, and shared server management for teams. URL: https://mapledeploy.ca/docs/organizations Organizations let teams share access to the same MapleDeploy servers and subscriptions. Servers, billing, trial eligibility, and members belong to the organization. When you create a MapleDeploy account, we create a personal organization for you and make you the owner. If you create an account from an invitation link, your account joins the inviting organization instead. ## Roles Choose the least-powerful role that lets a teammate do their job: | Role | Best for | Access | | ---- | -------- | ------ | | Owner | The primary administrator | Full organization, server, billing, and membership access | | Admin | Trusted teammates who help manage the account | Can manage servers, invitations, members, and billing self-service | | Member | Teammates who need visibility or Coolify deployment access | Can view servers, snapshots, member lists, and billing summaries | Contact [support@mapledeploy.ca](mailto:support@mapledeploy.ca) if you need help changing the owner. Members cannot create paid resources, change organization settings, manage teammates, or open Stripe billing. MapleDeploy Members are read-oriented in the MapleDeploy dashboard. Coolify access is separate. A Member who sets up a Coolify login can deploy and manage resources inside Coolify. See [Coolify team access](/docs/coolify-access). ## Invitations Owners and admins can invite teammates from **Settings** > **Organization**. 1. Enter the teammate's email address. 2. Choose **Member** or **Admin**. 3. Send the invitation. The recipient gets an email with a link to join the organization. The invitation is tied to that email address, so the recipient must sign in or create an account with the same address. Invitations expire after 7 days. Sending a new invitation to the same email address cancels the previous pending invitation and creates a fresh link. To re-send an invitation, send a new invitation to the same email address. To cancel one, find it under **Pending invitations** and select **Cancel**. ## Accept an invitation If you already have a MapleDeploy account: 1. Open the invitation link. 2. Sign in if needed. 3. Review the organization and role. 4. Accept or decline the invitation. If your existing account belongs to a different organization, contact support before accepting the invitation. If you do not have a MapleDeploy account: 1. Open the invitation link. 2. Choose **Create account**. 3. Create the account with the invited email address. 4. Return to the invitation page and finish joining the organization. ## Billing Billing is organization-owned. Each organization has one billing profile, and each server has its own subscription. See [plans and pricing](/#pricing) for plan pricing and trial details. All organization members can see active subscriptions and the saved payment method summary. Members cannot open Stripe invoices, edit payment details, update the billing contact, or cancel subscriptions. Owners and admins can use **Settings** > **Billing** to: - View active subscriptions by server. - See subscription status, plan, monthly price, and next billing date. - Cancel eligible subscriptions. - Open the Stripe billing portal when a card is on file. Card data is handled by Stripe and is not stored by MapleDeploy. ## Trials Trial eligibility belongs to the organization, not the individual user. Starter and Pro include a 30-day free trial when the organization has not already used a trial. Ultra plans do not include a trial. If an owner or admin creates another server in the same organization, that server uses the organization's trial eligibility and billing profile. ## Common workflows ### Change a member's role 1. Go to **Settings** > **Organization**. 2. Find the member in **Members**. 3. Change the role to **Admin** or **Member**. Role changes are available to owners and admins. ### Remove a member 1. Go to **Settings** > **Organization**. 2. Find the member in **Members**. 3. Select **Remove**. Removing a member also removes their MapleDeploy dashboard access to the organization. For Coolify offboarding, see [Coolify team access](/docs/coolify-access). ### Review billing 1. Go to **Settings** > **Billing**. 2. Review the organization's subscriptions. 3. If you are an owner or admin, select **Manage billing** to open the Stripe portal. ### Cancel a server subscription 1. Sign in as an owner or admin. 2. Go to **Settings** > **Billing**. 3. Find the server subscription. 4. Select **Cancel**. 5. Confirm the cancellation. Canceling a server subscription powers the server off right away and pauses billing for it. After a 7-day grace period, the server is permanently deleted and the subscription ends. During those 7 days you can revert the cancellation from the server page, and the server powers back on. After deletion, a recovery snapshot is kept for 30 days. --- ## Platform as a service in Canada with git push deploys A platform as a service in Canada. Connect your repo, push to your branch, and MapleDeploy builds your app with SSL included. No servers to manage. URL: https://mapledeploy.ca/git-push-deploys {% hero-section title="Your Platform as a Service in Canada" %} Connect your repo. Push to your branch. Every push triggers a deploy with SSL included. No infrastructure to manage. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} MapleDeploy is a managed platform as a service (PaaS) on Canadian infrastructure. No DevOps expertise required. No Kubernetes clusters to configure. No nginx files to write. Just your code and a git push. We handle server provisioning, security hardening, SSL certificates, and updates. You focus on building your product. {% /intro-section %} {% icon-feature-grid title="We configure the server, you push the code:" %} {% icon-feature-item icon="refresh" title="Automatic builds" %} Your app builds automatically, no config files needed {% /icon-feature-item %} {% icon-feature-item icon="database" title="Managed databases" %} Postgres, MySQL, Redis, MongoDB in one click {% /icon-feature-item %} {% icon-feature-item icon="globe" title="Custom domains" %} Point your DNS, SSL provisions automatically {% /icon-feature-item %} {% icon-feature-item icon="lock" title="Automatic SSL" %} HTTPS certificates provision and renew automatically. No configuration needed. {% /icon-feature-item %} {% /icon-feature-grid %} {% numbered-steps-section title="How it works" %} {% numbered-step number=1 title="Connect your repository" %} Link your GitHub, GitLab, or Bitbucket account. Select your repo and branch. {% /numbered-step %} {% numbered-step number=2 title="We detect your stack" %} MapleDeploy automatically identifies your framework and configures the build. Most popular stacks are supported out of the box. {% /numbered-step %} {% numbered-step number=3 title="Push and you're live" %} Every push to your branch triggers a deploy. Your app goes live after the build completes, ready for production traffic. {% /numbered-step %} {% /numbered-steps-section %} {% image-content-section title="Watch your server come online" src="dashboard-provisioning-progress-zoom-card" width=704 height=740 %} Your dedicated VM provisions in minutes. Track each step in real time from the dashboard, from server creation through to Coolify installation. No tickets, no waiting. {% /image-content-section %} {% checklist-section title="What you can deploy" subtitle="If it runs on Linux, it runs on MapleDeploy." %} - Node.js, Python, Ruby, Go, PHP, Java - Next.js, Nuxt, SvelteKit, Remix - Django, Rails, Laravel, Express - Static sites and SPAs - APIs and backend services - Docker containers {% /checklist-section %} {% feature-grid-section title="Beyond the deploy" %} {% feature-card icon="refresh" title="PR preview environments" %} Every pull request gets its own preview URL. Share it with your team, test it, and it cleans up automatically when the PR merges. {% /feature-card %} {% feature-card icon="database" title="One-click rollbacks" %} Something break after a deploy? Roll back to a previous version in seconds from the dashboard. No CLI commands, no revert commits. {% /feature-card %} {% feature-card icon="terminal" title="Logs and alerts" %} Stream real-time logs from any service. Get deployment notifications via Discord, Telegram, or email so you always know what's happening. {% /feature-card %} {% /feature-grid-section %} {% content-section title="Canadian infrastructure included" %} Every MapleDeploy plan runs on Canadian servers in Toronto data centers. Your application data stays under Canadian jurisdiction, governed by Canadian privacy law, not subject to the US CLOUD Act or foreign data requests. You shouldn't have to choose between simple deploys and Canadian infrastructure. MapleDeploy gives you both. Your servers, databases, and application data are all in Canada. Whether that matters for compliance or just because you prefer it, it's included on every plan. {% /content-section %} {% content-section title="Built on open source" %} MapleDeploy runs on [Coolify](/open-source-stack), an open-source deployment platform with over 50,000 GitHub stars. You can inspect exactly how your deployments work, read the source code, and understand the system that runs your apps. Simple doesn't mean opaque. We believe you should be able to understand your hosting stack without needing a PhD in distributed systems. When something goes wrong, you can actually debug it, not just wait for a support ticket response. {% /content-section %} {% cta-section title="Ready to deploy?" button-text="Start free trial" %} 30 days free. Deploy a real project, use real databases, and see how simple it can be. See the [step-by-step guide](/docs/deploy-your-first-app) to go from signup to a live app. {% /cta-section %} --- ## MapleDeploy - The Canadian PaaS with git push deploys A Canadian platform as a service (PaaS) with git push deploys, managed databases, and flat pricing. No US jurisdiction, no surprises. URL: https://mapledeploy.ca/ {% content-section title="Why this exists" %} It started with a simple goal: run my projects on Canadian infrastructure. That turned out to be surprisingly difficult. Every developer-friendly platform as a service (PaaS) was a US company under US jurisdiction: Heroku, Railway, Render, Vercel. Whether you need Canadian hosting for compliance or just prefer it on principle, the options were the same: none. So I built what I was looking for: a Canadian deployment platform with the modern PaaS experience, and no US cloud underneath. Your code and your data, on Canadian soil. {% signature %} – [Ross Hill](https://rosshill.ca) {% /signature %} {% /content-section %} {% image-content-section title="From sign-up to deploy in minutes" src="dashboard-provisioning-progress-zoom-card" image-position="left" width=704 height=740 %} Watch your VM spin up in real time with live provisioning updates. Once ready, manage deployments, databases, domains, and backups from one dashboard. No tickets, no waiting. {% /image-content-section %} {% numbered-steps-section title="Your first deployment" %} {% numbered-step number=1 title="Connect your repo" %} Open your Coolify dashboard, connect your GitHub or GitLab account, and point it at a repository. Coolify detects your framework automatically. {% /numbered-step %} {% numbered-step number=2 title="Push and you're live" %} Push to your branch. Coolify builds, deploys, and issues an SSL certificate. Your app is running on a dedicated Canadian VM with a live URL. {% /numbered-step %} {% numbered-step number=3 title="Add a database if you need one" %} One click for PostgreSQL, MySQL, Redis, or MongoDB. Connection details are ready to copy into your app's environment variables. No separate add-on billing. {% /numbered-step %} {% /numbered-steps-section %} {% feature-grid-section id="features" title="Why MapleDeploy" %} {% feature-card icon="server" title="Canadian data residency" %} Your code and your data stay in Canada, governed by Canadian law. Built for PIPEDA compliance, with GDPR adequacy status and no CLOUD Act exposure. {% /feature-card %} {% feature-card icon="cloud" title="Deploys that just work" %} Git push and you're live. Automatic SSL. One-click PostgreSQL, MySQL, Redis, MongoDB. [Coolify managed hosting](/open-source-stack) that makes deployment feel like it should. {% /feature-card %} {% feature-card icon="dollar" title="Pricing you can predict" %} Starting at $45 CAD/month for a dedicated VM that's entirely yours. No per-project fees, no usage charges, no surprise bills at the end of the month. {% /feature-card %} {% /feature-grid-section %} {% checklist-section title="What you can deploy" subtitle="Anything that runs in a Docker container or deploys via Git:" footer="If it runs on Linux, it runs on MapleDeploy." %} - Node.js, Python, Ruby, Go, PHP, Java - Static sites and SPAs - APIs and backend services - Full-stack apps with managed databases {% /checklist-section %} {% image-content-section title="300+ one-click services" src="coolify-one-click-services-zoom-grid" width=1664 height=1094 %} WordPress, Supabase, Grafana, N8N, Ollama, and hundreds more. Deploy pre-configured services alongside your app with one click. No per-service billing, no third-party providers. {% /image-content-section %} {% icon-feature-grid title="Production-ready from day one" %} {% icon-feature-item icon="refresh" title="PR preview environments" %} Every pull request gets its own preview URL with automatic cleanup. Test changes in isolation before merging. {% /icon-feature-item %} {% icon-feature-item icon="terminal" title="Real-time logs and alerts" %} Stream logs from any service. Get deployment notifications via Discord, Telegram, or email. {% /icon-feature-item %} {% icon-feature-item icon="database" title="One-click rollbacks" %} Something break? Roll back to a previous deployment in seconds from the Coolify dashboard. {% /icon-feature-item %} {% icon-feature-item icon="shield" title="Isolated by default" %} Each customer gets their own VM with dedicated resources. No shared containers, no noisy neighbors, no cross-tenant access. {% /icon-feature-item %} {% icon-feature-item icon="lock" title="Secrets and environment variables" %} Manage environment variables per service from the dashboard. Secrets stay encrypted in the database, and values you lock in Coolify are redacted from application deployment logs. {% /icon-feature-item %} {% icon-feature-item icon="cloud" title="Weekly full-server snapshots included" %} Weekly full-server snapshots with 30-day post-cancellation retention. Plus Coolify's built-in database backup to S3-compatible storage for granular control. {% /icon-feature-item %} {% /icon-feature-grid %} {% image-content-section title="Real-time server monitoring" src="coolify-server-metrics-zoom-charts" image-position="left" width=1664 height=920 %} Track CPU and memory usage directly from the Coolify dashboard. See resource utilization in real time so you always know how your server is performing. No third-party monitoring setup required. {% /image-content-section %} {% pricing-section title="Pricing" subtitle="One dedicated VM, fully yours. Deploy multiple apps, databases, and services. No usage fees, just one flat price." currency-disclaimer="Approximate conversion based on current exchange rates. All billing is in CAD." /%} {% content-section title="Coolify managed hosting, done right" size="narrow" %} MapleDeploy runs on **Coolify**, an open-source deployment platform with over 60,000 GitHub stars. The entire deployment stack is auditable. No proprietary black boxes, no mystery infrastructure. You can read every line of code that handles your deployments, trace how builds work, and understand exactly what runs on your server. That transparency is not incidental. It is the point. MapleDeploy handles server provisioning, security hardening, and ongoing server maintenance so you can focus on your product. You deploy your apps, configure domains, and manage databases through the Coolify dashboard. We handle everything underneath. {% /content-section %} {% faq-section title="FAQ" /%} {% cta-section title="Get started" %} Try MapleDeploy free for 30 days. Deploy a real project, see if it fits. {% /cta-section %} --- ## Coolify Managed Hosting in Canada Coolify managed hosting you can fully understand. MapleDeploy runs on a stack you can trace: Coolify, Canadian cloud infrastructure, CIRA Canadian Shield. URL: https://mapledeploy.ca/open-source-stack {% hero-section title="Coolify Managed Hosting You Can Fully Understand" %} No black boxes. MapleDeploy runs on open-source Coolify and documented Canadian infrastructure. Every layer is visible and verifiable. {% button href="https://app.mapledeploy.ca/signup" size="large" %} Start your free trial {% /button %} {% /hero-section %} {% intro-section %} Trace every layer of your hosting stack, from deployment platform to data center to DNS. Most hosting platforms are opaque. You push code and something happens behind a proprietary system you can't inspect. With MapleDeploy, whether you value transparency on principle or need answers for a compliance audit, everything is specific and verifiable. {% /intro-section %} {% content-section title="Our stack" %} {% stack-item title="Coolify" url="https://github.com/coollabsio/coolify" link-text="view upstream source" %} Open-source deployment platform with 60,000+ GitHub stars. Handles git deployments, SSL certificates, database provisioning, and environment management. MapleDeploy runs a [fork of Coolify](https://forgejo.mapledeploy.ca/rosslh/coolify) that we rebase regularly against upstream. Our changes cover Canadian branding, MapleDeploy-specific integrations, disabled upstream telemetry, and the settings we manage for you. The fork is public, so you can review exactly what we've changed. {% /stack-item %} {% stack-item title="Canadian cloud infrastructure" %} Privately owned Canadian infrastructure provider with a data center in Toronto. Canadian-incorporated, with no US parent company. Your servers run on Canadian soil. See our [Canadian ownership verification](/legal/canadian-ownership) for how we check this. {% /stack-item %} {% stack-item title="CIRA Canadian Shield" %} Privacy-respecting DNS service operated by the Canadian Internet Registration Authority, the non-profit that manages the .ca domain. No tracking, no data selling, fully Canadian-operated. Your DNS queries resolve through Canadian infrastructure. {% /stack-item %} {% /content-section %} {% feature-grid-section title="What MapleDeploy manages for you" description="Here's what you'd handle yourself with upstream Coolify, and what MapleDeploy takes care of for you." columns=3 %} {% feature-card icon="server" title="Server provisioning" %} Sign up, pick a plan, and your Coolify instance is ready in minutes. Dedicated VM in Toronto with its own RAM and storage. No other customers on your server. {% /feature-card %} {% feature-card icon="shield" title="Security hardening" %} SSH key authentication, fail2ban, blocked outbound SMTP, and automatic security patches. The server is hardened before you ever log in. {% /feature-card %} {% feature-card icon="refresh" title="OS patches and maintenance" %} Operating system updates, kernel patches, and security fixes are applied for you. No SSH sessions, no manual maintenance windows. {% /feature-card %} {% /feature-grid-section %} {% content-section title="Want to self-host?" %} Because MapleDeploy runs on a fork of open-source Coolify, you're never locked in. If you ever want to bring your infrastructure in-house, you can deploy upstream Coolify on your own servers and migrate your applications over. Same platform, same deployment flow, under your complete control. Both upstream Coolify and our fork are open source under the Apache 2.0 license, free to use, modify, and deploy. MapleDeploy exists for teams who want Coolify managed hosting with Canadian infrastructure and someone else handling the server maintenance. {% /content-section %} {% info-card-section title="Why this matters" %} {% info-card title="For your peace of mind" %} No proprietary magic you can't inspect. If you want to understand how something works, the source code is right there on GitHub. You own your stack. {% /info-card %} {% info-card title="For your clients" %} When they ask about your infrastructure, you can answer precisely. Not vague hand-waving, but specific, verifiable answers about what runs where. {% /info-card %} {% info-card title="For compliance" %} Procurement teams love specifics. We can document exactly what software runs your app, where your data lives, and who operates it. {% /info-card %} {% info-card title="For portability" %} Your apps deploy as standard Docker containers using Dockerfiles or Nixpacks. Your data lives in standard databases you can export anytime. No proprietary build system or storage format to escape. {% /info-card %} {% /info-card-section %} {% cta-section title="See for yourself" hide-button=true %} Transparent infrastructure, transparent pricing. Starting at $45 CAD/month, everything included. Follow our [getting started guide](/docs/deploy-your-first-app) to deploy your first app. {% button href="https://github.com/coollabsio/coolify" variant="secondary" size="large" %} View Coolify source {% /button %} {% /cta-section %}