Merge branch 'main' of https://github.com/tokifyi/defang-docs

Author: tokifyi

blog/2024-11-13-october-product-updates.md

@@ -55,15 +55,6 @@ The team is now heads-down dotting the i’s and crossing the t’s so we can re
 
 <img src="/img/october-update/coffee-chat.png" alt="CoffeeChat" style={{ width: 300 }} />
 
-## Defang Coffee Chat ☕
-
-If you're excited about what's coming next and want to hear more about our vision for the future, join us for our Coffee Chat on November 27th 2024.
-We'll be sharing more about our roadmap and what we're working on next.
-
-<Button href="https://lu.ma/4n54sy2v" variant="contained" size="large" target="_blank">
-Register here!
-</Button>
-
 ---
 
 As always, we appreciate your feedback and are committed to making Defang the easiest way to develop, deploy, and debug your cloud applications. Go build something awesome! 🚀

blog/2025-03-07-feb-product-updates.md

@@ -0,0 +1,88 @@
+---
+slug: deploying-defang-with-defang-part-1
+title: "Deploying Defang with Defang: Part 1"
+author: Defang Team
+tags: [defang-with-defang, deployment, defang-portal]
+---
+
+![Defang Compose Update](/img/defang-on-defang/part-1/header.png)
+
+Deploying applications is hard. Deploying complex, multi-service applications is even harder. When we first built the Defang Portal, we quickly recognized the complexity required to deploy it, even with the early Defang tooling helping us simplify it a lot. But we’ve worked a lot to expand Defang’s capabilities over the last year+ so it could take on more of the work and simplify that process.
+
+This evolution wasn’t just based on our own instincts and what we saw in the Portal—it was informed by listening to developers who have been using Defang, as well as our experience building dozens of sample projects for different frameworks and languages. Each time we build a new sample, we learn more about the different requirements of various types of applications and developers and refine Defang’s feature set accordingly. The Portal became an extension of this learning process, serving as both a proving ground and an opportunity to close any remaining gaps, since it’s one of the most complex things we’ve built with Defang.
+
+Finally, though, the Defang Portal—an application with six services, including two managed data stores, authentication, and a frontend—is fully deployed using just Docker Compose files and the Defang CLI using GitHub Actions.
+
+---
+
+## **The Initial Setup: A More Complex Deployment**
+
+The Portal isn’t a simple static website; it’s a **full-stack application** with the following services:
+
+- **Next.js frontend** – Including server components and server actions.
+- **Hasura (GraphQL API)** – Serves as a GraphQL layer.
+- **Hono (TypeScript API)** – Lightweight API for custom business logic.
+- **OpenAuth (Authentication Service)** – Manages authentication flows.
+- **Redis** – Used for caching and session storage.
+- **Postgres** – The main database.
+
+Initially, we provisioned databases and some DNS configurations using Infra-as-Code because Defang couldn’t yet manage them for us. We also deployed the services themselves manually through infrastructure-as-code, requiring us to define each service separately.
+
+This worked, but seemed unnecessarily complex, if we had the right tooling…
+
+---
+
+## **The Transition: Expanding Defang to Reduce Complexity**
+
+We’ve made it a priority to expand Defang’s capabilities a lot over the last year so it could take on more of the heavy lifting of a more complex application. Over the past year, we’ve added loads of features to handle things like:
+
+- **Provisioning databases**, including managing passwords and other secrets securely
+- **Config interpolation using values stored in AWS SSM**, ensuring the same Compose file works both locally and in the cloud
+- **Provisioning certs and managing DNS records** from configuration in the Compose file.
+
+As a result, we reached a point where we no longer needed custom infrastructure definitions for most of our deployment.
+
+## **What Changed?**
+
+- **Previously**: GitHub Actions ran infra-as-code scripts to provision databases, manage DNS, and define services *separately from the Docker Compose file we used for local dev*
+- **Now**: Our [**Defang GitHub Action**](https://github.com/marketplace/actions/defang-deployment-action) targets normal Compose files and deploys everything, using secrets and variables managed in GitHub Actions environments.
+- **Result**: We **eliminated hundreds of lines of Infra-as-Code**, making our deployment leaner and easier to manage and reducing the differences between running the Portal locally and running it in the cloud.
+
+This wasn’t just about reducing complexity—it was also a validation exercise. We knew that Defang had evolved enough to take over much of our deployment, but by going through the transition process ourselves, we could identify and close the remaining gaps and make sure our users could really make use of Defang for complex production-ready apps.
+
+---
+
+## **How Deployment Works Today**
+
+### **Config & Secrets Management**
+
+- **Sensitive configuration values** (database credentials, API keys) are stored **securely in AWS SSM** using Defang’s [configuration management tooling](https://docs.defang.io/docs/concepts/configuration).
+- [**Environment variable interpolation**](https://docs.defang.io/docs/concepts/configuration#interpolation) allows these **SSM-stored config values** to be referenced directly in the Compose file, ensuring the same configuration works in local and cloud environments.
+- **Defang provisions managed Postgres and Redis instances automatically** when using the `x-defang-postgres` and `x-defang-redis` extensions, securely injecting credentials where needed with variable interpolation.
+
+### Deployment Modes
+
+- [**Deployment modes**](https://docs.defang.io/docs/concepts/deployment-modes) (`development`, `staging`, `production`) adjust infrastructure settings across our dev/staging/prod deployments making sure dev is low cost, and production is secure and resilient.
+
+### **DNS & Certs**
+
+- When we first set up the portal (before we even released the private beta) DNS and certs had to be managed outside the Defang context. Now, **[we can provision certs using ACM or Let’s Encrypt](https://docs.defang.io/docs/concepts/domains)**.
+
+### **CI/CD Integration**
+
+- **Previously**: GitHub Actions ran custom infra-as-code scripts.
+- **Now**: The [**Defang GitHub Action**](https://github.com/DefangLabs/defang-github-action) installs Defang automatically and runs `defang compose up`, simplifying deployment.
+- **Result**: A streamlined, repeatable CI/CD pipeline.
+
+---
+
+## **The Takeaway: Why This Matters**
+
+By transitioning to **fully Compose-based deployments**, we:
+
+* ✅ **Eliminated hundreds of lines of Infra-as-Code**
+* ✅ **Simplified configuration management** with secure, environment-aware secrets handling
+* ✅ **Streamlined CI/CD** with a lightweight GitHub Actions workflow
+* ✅ **Simplified DNS and cert management** 
+
+Every sample project we built, every conversation we had with developers, and every challenge we encountered with the Portal helped us get to this point where we could focus on closing the gaps last few gaps to deploying everything from a Compose file.

blog/2025-03-14-deploying-defang-with-defang-part-1.md

@@ -0,0 +1,28 @@
+---
+title: February 2025 Defang Compose Update
+tags:
+  [
+    Cloud,
+    DevOps,
+    Pulumi,
+    Compose,
+    OpenAuth,
+    Portal,
+    Events,
+  ]
+author: Defang Team
+---
+
+![Defang Compose Update](/img/defang-compose-update.webp)
+
+Well, that went by quick! Seems like it was just a couple of weeks ago that we published the Jan update, and it’s already time for the next one. Still, we do have some exciting progress to report in this short month!
+
+1. **Pulumi Provider:** We are excited to announce a Preview of the [Defang Pulumi Provider](https://github.com/DefangLabs/pulumi-defang/). With the Defang Pulumi Provider, you can leverage all the power of Defang with all of the extensibility of Pulumi. Defang will provision infrastructure to deploy your application straight from your Compose file, while allowing you to connect that deployment with other resources you deploy to your cloud account. The new provider makes it easy to leverage Defang if you’re already using Pulumi, and it also provides an upgrade-path for users who need more configurability than the Compose specification can provide.
+2. **Portal Update:** We are now fully deploying our portal with Defang alone using the `defang compose up` command. Our original portal architecture was designed before we supported managed storage so we used to use Pulumi to provision and connect external storage. But since we added support in Compose to specify managed storage, we can fully describe our Portal using Compose alone. This has allowed us to rip out hundreds of lines of code and heavily simplify our deployments. To learn more about how we do this, check out our Defang-Deployed-with-Defang (Part 1) [blog](https://docs.defang.io/blog/deploying-defang-with-defang-part-1).
+3. **Open-Auth Contribution:** In the past couple months we have been communicating with the OpenAuth maintainers and contributors via PRs ([#120](https://github.com/toolbeam/openauth/pull/120), [#156](https://github.com/toolbeam/openauth/pull/156)) and Issues ([#127](https://github.com/toolbeam/openauth/issues/127)) to enable features like local testing with DynamoDB, enabling support for scopes, improving standards alignment, supporting Redis, and more. We are rebuilding our authentication systems around OpenAuth and are excited about the future of the project. 
+
+**Events and Social Media**
+
+February was an exciting month for the Defang team as we continued to engage with the developer community and showcase what’s possible with Defang. We sponsored and demo’ed at the [DevTools Vancouver meetup](https://lu.ma/devtools3), as well as sponsored the [Vancouver.dev IRL: Building AI Startups](https://lu.ma/vandevirl2) event. Also, at the AWS Startup Innovation Showcase in Vancouver, our CTO [Lio](https://www.linkedin.com/in/lionello/)  [demonstrated](https://www.linkedin.com/feed/update/urn:li:activity:7299861024780808193) how Defang makes it effortless to deploy secure, scalable, and cost-efficient serverless apps on AWS! And finally, we had a great response to our [LinkedIn post](https://www.linkedin.com/posts/defanglabs_mcp-docker-anthropic-activity-7298043665883508736-i4dd?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAAQqiEBLsVLYYAzEmBFB9oIl31nQ7kDII0) on the Model Context Protocol, catching the attention of many observers, including some of our key partners.
+
+We are eager to see what you deploy with Defang. Join our [Discord](http://s.defang.io/discord) to ask any questions, see what others are building, and share your own experience with Defang. And stay tuned for more to come in March!

blog/2025-03-15-feb-product-updates.md

@@ -0,0 +1,86 @@
+---
+slug: deploying-defang-with-defang-part-2
+title: "Deploying Defang with Defang: Part 2"
+author: Defang Team
+tags: [defang-with-defang, deployment, defang-website]
+---
+
+![Defang Compose Update](/img/defang-on-defang/part-2/header.png)
+
+When we refreshed the Defang brand, we knew our website needed more than just a fresh coat of paint. It needed to become a more dynamic part of our stack. We needed some parts to be more flexible, some parts to be more interactive, and better aligned with how modern apps are organized and deployed. And what better way to take it there than to deploy it with Defang itself?
+
+This is part of our ongoing "Defang on Defang" series, where we show how we're using our own tool to deploy all the services that power Defang. In this post, we're diving into how we turned our own website into a project to better understand how Defang can be used to deploy a dynamic Next.js apps and how we can improve the experience for developers.
+
+---
+
+## From S3 + CloudFront to Dynamic, Containerized Deployments
+
+Our original site was a Next.js app using [static exports](https://nextjs.org/docs/pages/building-your-application/deploying/static-exports) deployed via S3 and fronted by CloudFront. That setup worked for a while—it was fast and simple. But with our brand refresh, we added pages and components where it made sense to use (and test for other developers) some Next.js features that we couldn't use with the static export:
+
+- [React Server Components](https://nextjs.org/docs/app/building-your-application/rendering/server-components)
+- [Server Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations)
+- [ISR](https://nextjs.org/docs/app/building-your-application/data-fetching/incremental-static-regeneration)
+
+That meant static hosting wouldn't cut it. So we decided to run the site as an app in a container.
+
+That being said, our learnings from the previous setup *are* being used to develop the capabilities of Defang. We're using the experience to make sure that Defang can handle the deployment of static sites as well as dynamic ones. We'll keep you updated when that's ready.
+
+---
+
+## Deploying with Defang (and Why It Was Easy)
+
+We already deploy our other services with Defang using Compose files. In fact, the static website actually already used a Dockerfile and Compose file to manage the build process. So we just had to make some minor changes to the Compose file to take into account new environment variables for features we're adding and make a few small changes to the Dockerfile to handle the new build process.
+
+Some things we had to change:
+
+**Adding [ports](https://docs.defang.io/docs/concepts/compose#ports) to the Compose file**:
+```yaml
+    ports:
+      - mode: ingress
+        target: 3000
+        published: 3000
+```
+
+**Adding [domain](https://docs.defang.io/docs/concepts/domains) info the Composer file**:
+```yaml
+    domainname: defang.io
+    networks:
+      default:
+        aliases:
+          - www.defang.io
+```
+
+One other hiccup was that we used to do www to non-www redirects using S3. There are a few ways to switch that up, but for the time being we decided to use Next.js middleware.
+
+Pretty soon after that, the site was up and running in an AWS account—with TLS, DNS, and both the `www` and root domains automatically configured. Pretty straightfoward!
+
+---
+
+## Real-World Lessons That Are Shaping Defang
+
+Deploying the website wasn't just a checkbox—it helped surface real-world pain points and ideas for improvement.
+
+### 1. Static Assets Still Need CDNs
+Even though the site is dynamic now, we still want assets like `/_next/static` to load quickly from a CDN. This made it clear that CDN support—like CloudFront integration—should be easier to configure in Defang. That’s now on our roadmap. That's also going to be useful for other frameworks that use similar asset paths, like Django.
+
+### 2. Next.js Env Vars Can Be Tricky in Containers
+Next.js splits env vars between build-time and runtime, and the rules aren’t always obvious. Some need to be passed as build args, and others as runtime envs. That made us think harder about how Defang could help clarify or streamline this for developers—even if we can’t change that aspect of Next.js itself.
+
+### 3. Redirects and Rewrites
+We had to add a middleware to handle www to non-www redirects. This is a common need, so we're keeping an eye on how we can make this easier to deal with in Defang projects.
+
+These are the kinds of things we only notice by using Defang on real-world projects.
+
+---
+
+## The Takeaway
+
+Our site now runs like the rest of our infrastructure:
+
+- Fully containerized
+- Deployed to our own AWS account
+- Managed with a Compose file
+- Deployed with Defang
+
+Stay tuned for the next post in the series—because this is just one piece of the puzzle.
+