[{"content":"","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/","section":"Code Engine Blog","summary":"","title":"Code Engine Blog","type":"page"},{"content":"","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/documentation/","section":"Tags","summary":"","title":"Documentation","type":"tags"},{"content":"","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/guide/","section":"Tags","summary":"","title":"Guide","type":"tags"},{"content":"Welcome to the IBM Code Engine Developer Blog contribution guide! This site is powered by Hugo and built using the highly customizable Blowfish Theme.\nTo maintain a consistent reading experience, please follow this step-by-step workflow to configure your author bio, format your posts, and submit content.\n1. Setting Up Your Author Profile # Before writing your first post, you must create an author profile. This generates a rich bio card at the bottom of your articles and populates the global author index pages.\nCreate Your Author Directory: Navigate to content/authors/ in the repository. Create a new directory named exactly after your author handle (use lowercase and hyphens, e.g., content/authors/john-doe/). Create the Profile Configuration: Inside your new folder, create an _index.md file. This file holds your profile metadata and biography. Add Your Profile Image: Place an avatar image (JPG or PNG, ideally square) into your author folder. Name it avatar.jpg or avatar.png. Blowfish will detect and render it automatically. Author Template # Copy and paste this structure into your content/authors/\u0026lt;your-name\u0026gt;/_index.md file:\n--- title: \u0026#34;John Doe\u0026#34; searchHidden: true # Keeps your profile page out of general article searches # Social Media Links links: - github: \u0026#34;https://github.com/your-username\u0026#34; - linkedin: \u0026#34;https://linkedin.com/in/your-profile\u0026#34; - twitter: \u0026#34;https://twitter.com/your-handle\u0026#34; --- Write a short, engaging 2-3 sentence biography here. Explain your role at IBM, your technical focus areas (like Cloud Native Serverless systems, Kubernetes, or Knative), and what you enjoy working on outside of coding. 2. Creating a New Post # All articles are written in standard Markdown and live inside the content/posts/ directory.\nStep 1: Create the File # Create a new file named your-post-title.md inside content/posts/.\nStep 2: Configure Front Matter # Every article requires a block of configuration at the absolute top of the file, wrapped in triple hyphens (---). Use this exact template:\n--- title: \u0026#34;Deploying Microservices with Code Engine\u0026#34; date: 2026-05-27 description: \u0026#34;A deep dive into deploying containerized applications with minimal infrastructure configuration.\u0026#34; tags: [\u0026#34;code-engine\u0026#34;, \u0026#34;serverless\u0026#34;, \u0026#34;containers\u0026#34;] categories: [\u0026#34;tutorials\u0026#34;] author: \u0026#34;john-doe\u0026#34; # Must exactly match your folder name in content/authors/ showTaxonomies: true showAuthor: true showAuthorBottom: true --- Crucial Rule: Ensure the author string matches your author profile directory name exactly. If it doesn\u0026rsquo;t, your bio card won\u0026rsquo;t load and global author filtering will fail.\n3. Formatting and Styling Content # Blowfish includes rich utility components to make your content visually engaging. Make sure to review the Official Blowfish Content Structure Guide (https://blowfish.page/docs/content/) for comprehensive examples.\nCode Snippets and Syntax Highlighting # Always specify the programming language next to your opening backticks to enable clean code block rendering:\n// Example of clean syntax highlighting const client = new CodeEngineClient(); await client.deployApplication(\u0026#34;my-app\u0026#34;); Shortcodes and Alerts # Blowfish provides elegant custom components called \u0026ldquo;shortcodes\u0026rdquo; to call out critical details or warnings.\nAlert Boxes: Use these to emphasize specific configurations or caveats. Read more in the Blowfish Alert Shortcode Docs (https://blowfish.page/docs/shortcodes/#alert).\nNote: Code Engine projects automatically scale to zero instances when idle to save resource costs. Badges: Highlight small snippets of inline metadata using the Blowfish Badge Documentation (https://blowfish.page/docs/shortcodes/#badge).\n4. Submission Checklist # Before opening a Pull Request (PR) on GitHub, ensure you check off the following items:\nMy author profile exists under content/authors/ and contains an _index.md. The theme variable is not present in hugo.toml (all module imports are handled natively by Go Modules). All tags and categories are lowercase string arrays (e.g., tags: [\u0026quot;cloud\u0026quot;, \u0026quot;devops\u0026quot;]). I have verified all custom text comparison layouts use clean string descriptors instead of naked \u0026lt; or \u0026gt; characters to avoid parsing errors. All referenced images are placed contextually or within assets, avoiding broken links. For advanced stylistic tweaks, layout adjustments, or multi-language configurations, consult the complete Blowfish Theme Documentation Hub (https://blowfish.page/docs/).\n","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/posts/how-to-blog/","section":"Posts","summary":"Welcome to the IBM Code Engine Developer Blog contribution guide! This site is powered by Hugo and built using the highly customizable Blowfish Theme.\nTo maintain a consistent reading experience, please follow this step-by-step workflow to configure your author bio, format your posts, and submit content.\n1. Setting Up Your Author Profile # Before writing your first post, you must create an author profile. This generates a rich bio card at the bottom of your articles and populates the global author index pages.\n","title":"How to post on the Code Engine Dev Blog","type":"posts"},{"content":"","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/hugo/","section":"Tags","summary":"","title":"Hugo","type":"tags"},{"content":"","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/meta/","section":"Tags","summary":"","title":"Meta","type":"tags"},{"content":"","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"Welcome to my blog post feed.\n","date":"May 27, 2026","externalUrl":null,"permalink":"/CodeEngine/authors/uwefassnacht/","section":"Authors","summary":"Welcome to my blog post feed.\n","title":"Uwe Fassnacht","type":"authors"},{"content":"","date":"May 26, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/ai/","section":"Tags","summary":"","title":"AI","type":"tags"},{"content":"","date":"May 26, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/code-engine/","section":"Tags","summary":"","title":"Code Engine","type":"tags"},{"content":"","date":"May 26, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/gpu/","section":"Tags","summary":"","title":"GPU","type":"tags"},{"content":"","date":"May 26, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/news/","section":"Tags","summary":"","title":"News","type":"tags"},{"content":"The AI landscape is moving at a breakneck pace, and today we are shifting into a new gear. We are thrilled to announce that NVIDIA B300 (Blackwell Ultra) GPUs are now also available in IBM Cloud Code Engine Serverless Fleets.\nBy bringing NVIDIA’s most powerful Blackwell-architecture GPU to our serverless platform, we are giving developers the ability to run the world’s most demanding reasoning models and massive-scale simulations without the burden of infrastructure management.\nWhy Use B300 with Serverless Fleets? # “Serverless Fleets\u0026quot; make the B300 accessible and cost-effective. While Blackwell GPUs are power-hungry (1,400W TDP) and expensive to reserve, Code Engine changes the economics:\nZero Idle Costs: The B300 is a high-performance asset. In a traditional setup, you pay for it 24/7. With Code Engine, your Fleet scales to zero when your job is done. Billing starts the moment a GPU is initialized, and you are only charged for the GPU‑seconds it is active.\nMassive Parallelism without the Headaches: Serverless Fleets allow you to submit thousands of tasks to a single endpoint. Code Engine automatically provisions the B300 resources, distributes the tasks, and decommissions the GPUs when the work is complete.\nBlackwell-Ready Abstraction: No need to configure liquid cooling or 800Gbps networking. We handle the intense infrastructure requirements of the Blackwell architecture so you can focus on your vllM or PyTorch code.\nSeamless Model Fitting: The massive 288GB VRAM means you can run larger batch sizes or longer context windows (up to 128k+ tokens) on a single node, significantly reducing the latency overhead of inter-GPU communication.\nReady to Scale? # Whether you are fine-tuning the latest Granite models or running high-throughput inference for a global application, the B300 on Code Engine is your new high-performance home.\nGet Started: View the Code Engine Serverless Fleets documentation to learn how to configure your first GPU-enabled fleet.\nStep-by-Step Tutorial: Follow our GPU Batch Processing tutorials on GitHub for real-world examples.\nPricing \u0026amp; Profiles: Visit the IBM Cloud Pricing Page to see the latest rates for B300 GPU-second billing and choose the right worker profile for your workload.\nThe era of Blackwell has arrived. Scale your intelligence, not your operations.\n","date":"May 26, 2026","externalUrl":null,"permalink":"/CodeEngine/posts/b300-now-available/","section":"Posts","summary":"The AI landscape is moving at a breakneck pace, and today we are shifting into a new gear. We are thrilled to announce that NVIDIA B300 (Blackwell Ultra) GPUs are now also available in IBM Cloud Code Engine Serverless Fleets.\nBy bringing NVIDIA’s most powerful Blackwell-architecture GPU to our serverless platform, we are giving developers the ability to run the world’s most demanding reasoning models and massive-scale simulations without the burden of infrastructure management.\n","title":"NVIDIA B300 GPUs Now Available in IBM Cloud Code Engine Serverless Fleets","type":"posts"},{"content":"","date":"May 26, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/serverless/","section":"Tags","summary":"","title":"Serverless","type":"tags"},{"content":"","date":"May 26, 2026","externalUrl":null,"permalink":"/CodeEngine/tags/serverless-fleets/","section":"Tags","summary":"","title":"Serverless Fleets","type":"tags"},{"content":"","date":"November 26, 2025","externalUrl":null,"permalink":"/CodeEngine/tags/github-actions/","section":"Tags","summary":"","title":"Github Actions","type":"tags"},{"content":" Introduction # IBM Cloud Code Engine is IBM’s fully managed, strategic serverless platform that lets you run container images, batch jobs, source code, and functions in the cloud — without worrying about infrastructure management or scalability. It’s designed to simplify cloud-native development so you can focus on building, your business logic, not managing infrastructure. To make the developer experience even smoother, we introduced the IBM Cloud Code Engine GitHub Action. This action allows you to automate the build and deployment of your apps, jobs, and functions directly to Code Engine from your GitHub workflows.\nAnd now, it just got even better!\nWe’re excited to announce new capabilities that take automation and flexibility to the next level:\nBuild from Source with Ease: # The action now supports building a container image directly from your source code and storing it in IBM Cloud Container Registry — ready for deployment.\nMultiple Build Strategies: # Buildpacks (default): No Dockerfile required! Perfect for quick builds without extra configuration. Dockerfile: For developers who want full control over their build process. Image Support for Apps and Jobs: # Instead of building and deploying every time, you can now reference existing container images, including private ones. This opens the door to advanced workflows, such as multi-stage builds or integrating with external CI/CD pipelines.\nWith these enhancements, getting your workloads into the cloud has never been easier — or more powerful.\nGetting Started # Before diving into the examples, it’s important to prepare your repository for seamless integration with IBM Cloud Code Engine. Here’s what you need to do:\nPrerequisites # First, enable GitHub Actions for your repository. This can be done an a per repository basis. If your repository isn’t already enabled for GitHub Actions, check your access permissions, and reach out to the administrator of the GitHub organization.\nIBM Cloud account preparations # If you’re building a proof of concept or trying out the Code Engine for the first time, create an IBM Cloud API Key to authenticate your workflows with IBM Cloud services. For production-grade workloads create an IBM Cloud service ID API Key to authenticate your workflows with IBM Cloud services, as described below:\nNavigate to Manage → Access (IAM) → Service IDs . Click Create service ID, give it a name, assign Access policies to Resource group only, Code Engine and Container Registry. Then create a API key and copy the generated key for later use. See the documentation for additional information. Regardless whether you are using a personal API Key, or a service ID API Key, store it’s value as a GitHub secret:\nOn GitHub.com, navigate to your repository and go to Settings → Secrets and variables → Actions. Create a new secret named IBM_IAM_API_KEY (or any name you prefer) and paste the API key you\u0026rsquo;ve generated. Congratulations, your repository is now ready to leverage the IBM Cloud Code Engine GitHub Action. Let’s move on to the exciting part — exploring the new functionalities with hands-on examples! This blog post, uses pretty simple hello world examples. If you’re looking for more advanced code examples and sample workflows, be sure to check out the Code Engine Sample Repository, or revisit my initial blogpost IBM Cloud Code Engine: Deploying Apps, Jobs and Functions using GitHub Actions that showcased the Code Engine GitHub Action.\nBuilding and Pushing a Container Image to IBM Container Registry (ICR) Using Code Engine: # Start by creating a directory my-ce-app containing the source code you want to build and push to ICR using Code Engine build run. Inside the my-ce-app directory create the following files which make up a simple Node.JS Web Server.\napp.js\nconst express = require(\u0026#34;express\u0026#34;); const app = express(); const port = 8080; app.use(express.urlencoded({ extended: true })); app.use(express.json()); app.get(\u0026#34;/\u0026#34;, (req, res) =\u0026gt; { res.setHeader(\u0026#34;Content-Type\u0026#34;, \u0026#34;application/json\u0026#34;); res.status(200).send(JSON.stringify({ body: \u0026#34;Hello from Node\u0026#34; })); }); const server = app.listen(port, () =\u0026gt; { console.log(`Example app listening at http://localhost:${port}`); }); process.on(\u0026#34;SIGTERM\u0026#34;, () =\u0026gt; { console.info(\u0026#34;SIGTERM signal received.\u0026#34;); server.close(() =\u0026gt; { console.log(\u0026#34;Http server closed.\u0026#34;); }); }); package.json\n{ \u0026#34;dependencies\u0026#34;: { \u0026#34;express\u0026#34;: \u0026#34;^4.17.1\u0026#34; } } build-push.yml\nname: Build and Push to ICR on: push: branches: - main jobs: app: runs-on: ubuntu-latest steps: - name: Check out code uses: actions/checkout@v3 - name: Build and Push to ICR id: build-step uses: ibm/code-engine-github-action@v1 with: api-key: ${{ secrets.IBM_IAM_API_KEY }} region: \u0026#39;eu-de\u0026#39; project: \u0026#39;MY-PROJECT\u0026#39; component: \u0026#39;build\u0026#39; name: \u0026#39;my-ce-app\u0026#39; image: private.de.icr.io/my-namespace/my-image:latest registry-secret: ce-auto-icr-private-eu-de build-source: \u0026#39;./my-ce-app\u0026#39; - name: Get image with digest run: | echo \u0026#34;Image with digest: ${{ steps.build-step.outputs.image-with-digest }}\u0026#34; Next, inside of the .github/workflows create the following GitHub Action workflow YAML called build-push.yml. The workflow called \u0026ldquo;Build and Push to ICR\u0026rdquo; is executed when a push occurs against the main branch of the repository. Initially, it checks out the repository. In the next step, the ibm/code-engine-github-action will be used to build the container image (component: build) using Code Engine build run functionality and push the resulting container image to private ICR in eu-de using the auto generated registry secret created by Code Engine this can be omitted as this is the default value for the Code Engine GitHub Action. The build will be directed to the project MY-PROJECT within your default resource group in the Frankfurt region (eu-de). The build run will be named my-ce-build appended with the current timestamp the resulting image will be named private.de.icr.io/my-namespace/my-image:latest, utilizing the content of the my-ce-app directory as the source code used for the build step. The image refrerence and its digest is outputted for use in subsequent steps using ${{ steps.build-step.outputs.image-with-digest }}. For more information about Code Engine Push see the Code Engine Build Docs.\nPlease note: The example depicted above uses my-namespace as the IBM Container Registry namespace. As namespaces are unique, you\u0026rsquo;ll need to use your own one.\nBuilding and Deploying Your Code Engine App Using the Dockerfile Build Strategy # If you need more control over the build process \u0026ndash; such as adding custom dependencies, performance optimzation, or fine-tuning configurations \u0026ndash; the Dockerfile build strategy is the way to go. Unlike buildpacks, which handle most of the heavy lifting automatically, Dockerfile gives you full flexibility for advanced use cases. Start by organizing your application source (main.go) code and a Dockerfile inside the my-docker-app directory. This directory will contain everything needed to build your container image.\nmain.go\npackage main import ( \u0026#34;fmt\u0026#34; \u0026#34;net/http\u0026#34; \u0026#34;time\u0026#34; ) func greet(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, \u0026#34;Hello World! %s\u0026#34;, time.Now()) } func main() { http.HandleFunc(\u0026#34;/\u0026#34;, greet) http.ListenAndServe(\u0026#34;:3000\u0026#34;, nil) } Dockerfile\nFROM quay.io/projectquay/golang:1.24 AS build-env WORKDIR /go/src/app COPY main.go main.go RUN CGO_ENABLED=0 go build -o /go/bin/app main.go FROM gcr.io/distroless/static-debian12 EXPOSE 3000 COPY --from=build-env /go/bin/app / ENTRYPOINT [\u0026#34;/app\u0026#34;] build-dockerfile-app.yml\nname: Deploy App to Code Engine using Dockerfile build-strategy on: push: branches: - main workflow_dispatch: jobs: deploy-app: runs-on: ubuntu-latest steps: - name: Check out code uses: actions/checkout@v3 - name: Deploy App to Code Engine using Dockerfile build-strategy uses: IBM/code-engine-github-action@v1 with: api-key: ${{ secrets.IBM_IAM_API_KEY }} resource-group: \u0026#39;Default\u0026#39; region: \u0026#39;eu-de\u0026#39; project: \u0026#39;MY-PROJECT\u0026#39; component: \u0026#39;app\u0026#39; build-strategy: \u0026#39;dockerfile\u0026#39; port: 3000 name: \u0026#39;my-docker-app\u0026#39; build-source: \u0026#39;./my-docker-app\u0026#39; cpu: 1 memory: 4G Next, navigate to the .github/workflows directory and create a new GitHub Actions workflow file named build-dockerfile-app.yml. This workflow is responsible for automating the build and deployment process for your application. Specifically, it will use IBM Cloud Code Engine to build the application from the source code located in the my-docker-app directory, leveraging the provided Dockerfile to create the container image. Once the image is successfully built, the workflow will deploy it as a Code Engine application, ensuring a streamlined and reproducible CI/CD pipeline.\nDeploying an Existing Container Image to Code Engine as an Application # If you already have a container image built elsewhere \u0026ndash; perhaps as part of another CI/CD pipeline or stored in a private registry \u0026ndash; you can now deploy it directly to IBM Cloud Code Engine without rebuilding. This feature is perfect for teams that want to reuse pre-built images or integrate Code Engine into existing workflows. Inside of the .github/workflows create the following GitHub Action workflow YAML called my-img-app.yml. Instead of specifying source code or a build strategy, you reference the container image you want to deploy. This can be an image stored in IBM Container Registry (ICR) or any other registry, including private ones. We will be using the Code Engine Hello World image: icr.io/codeengine/helloworld:latest. In your workflow configuration, you’ll define key parameters like the project name, region, and resource group, along with the image reference and application settings (such as CPU and memory). Once triggered \u0026ndash; either on a push to the main branch or manually \u0026ndash; the workflow will deploy your application to Code Engine using the specified image.\nmy-img-app.yml\nname: Deploy Application to Code Engine using existing container image on: push: branches: - main workflow_dispatch: jobs: deploy-app: runs-on: ubuntu-latest steps: - name: Check out code uses: actions/checkout@v3 - name: Deploy Application to Code Engine using existing container image uses: IBM/code-engine-github-action@v1 with: api-key: ${{ secrets.IBM_IAM_API_KEY }} resource-group: \u0026#39;Default\u0026#39; region: \u0026#39;eu-de\u0026#39; project: \u0026#39;MY-PROJECT\u0026#39; component: \u0026#39;app\u0026#39; name: \u0026#39;my-img-app\u0026#39; image: icr.io/codeengine/helloworld:latest cpu: 1 memory: 4G These examples highlight how the new GitHub Action features make it easier to automate builds, manage deployments, and create advanced workflows for your cloud-native applications.\nConclusion # The IBM Cloud Code Engine GitHub Action makes deploying cloud-native workloads easier, faster, and more flexible than ever before. With support for multiple build strategies, image-based deployments, and seamless integration with GitHub Actions, you can automate your entire build-and-deploy pipeline without leaving your development workflow.\nWhether you’re building from source using buildpacks, fine-tuning with a Dockerfile, or deploying pre-built images from your registry, these new capabilities empower you to create advanced CI/CD workflows tailored to your needs. No more manual steps — just streamlined automation that gets your applications, jobs, and functions running in the cloud with minimal effort.\nGetting into the cloud has never been this easy — so why wait? Start automating your deployments now!\nCode Engine Code Engine Docs Example Code Code Engine Github Action Example Source Code IBM Cloud Code Engine: Deploying Apps, Jobs and Functions using GitHub Actions ","date":"November 26, 2025","externalUrl":null,"permalink":"/CodeEngine/posts/getting-into-the-cloud-just-got-a-lot-easier/","section":"Posts","summary":"Introduction # IBM Cloud Code Engine is IBM’s fully managed, strategic serverless platform that lets you run container images, batch jobs, source code, and functions in the cloud — without worrying about infrastructure management or scalability. It’s designed to simplify cloud-native development so you can focus on building, your business logic, not managing infrastructure. To make the developer experience even smoother, we introduced the IBM Cloud Code Engine GitHub Action. This action allows you to automate the build and deployment of your apps, jobs, and functions directly to Code Engine from your GitHub workflows.\n","title":"IBM Cloud Code Engine GitHub Action: Getting into the Cloud just got a lot easier!","type":"posts"},{"content":"Welcome to my blog post feed.\n","date":"November 26, 2025","externalUrl":null,"permalink":"/CodeEngine/authors/luke-roy-ibm/","section":"Authors","summary":"Welcome to my blog post feed.\n","title":"Luke Roy","type":"authors"},{"content":"IBM Cloud Code Engine is IBM’s fully managed, strategic serverless platform that empowers developers to run container images, batch jobs, source code, and functions — all in one unified environment. It abstracts away the complexity of infrastructure management, automatically handling scaling, networking, and security so you can focus on building and deploying your applications. With the introduction of Serverless Fleets, IBM Cloud Code Engine now supports large-scale, parallel execution of run-to-completion tasks across multiple virtual machines — securely hosted within your own Virtual Private Cloud (VPC). This gives you the flexibility to define custom subnets and choose from a wide range of Virtual Server Instance (VSI) flavors, including GPU-enabled options, tailored to your workload’s performance needs. What sets Code Engine apart is its serverless nature — it abstracts away the operational complexity of infrastructure management. You don’t need to worry about provisioning, scaling, or securing the underlying compute resources. Instead, you can focus entirely on your application logic and task definitions, while Code Engine handles the orchestration behind the scenes. By running Code Engine Serverless Fleets in a single-tenant environment, you gain enhanced control over performance, security, and compliance. This architecture ensures that your workloads execute in isolated infrastructure, making it ideal for enterprise-grade use cases such as video processing, AI inference, and scientific computing — all with a streamlined developer experience. Check out the introduction to Code Engine Serverless Fleets or look at the documentation.\nIn this blog post, we’ll explore a hands-on use case: upscaling video files using the Video2X framework powered by Real-ESRGAN, orchestrated entirely through IBM Cloud Code Engine Serverless Fleets with GPU support.\nTo follow along with this tutorial, you’ll need to have several IBM Cloud resources set up. These include an activated IBM Cloud account, a Code Engine project, and an IBM Cloud Object Storage instance configured with three COS buckets, each supporting built-in encryption and multi-region capabilities. The first bucket stores the data required to run your IBM Cloud Code Engine Serverless Fleets, the second holds the input files used by the fleet, and the third one is used to store the output files. Additionally, you’ll need a Virtual Private Cloud (VPC) with appropriately configured subnets.\nTo simplify the setup process, we’ll be using a one-time configuration script available in the following GitHub repository, which automatically provisions and configures all the required IBM Cloud resources. This approach is ideal for users who are new to Code Engine Serverless Fleets or want a quick start. However, if you’re already familiar with Code Engine and have an existing environment, feel free to customise or integrate the example setup to suit your current infrastructure.\nUpscaling the videos # Now that all the prerequisites for running Serverless Fleets on IBM Cloud Code Engine are in place, we can begin preparing our video upscaling use case. Start by uploading your video files to the designated COS input bucket. You can use the IBM Cloud UI, or any tool you’re comfortable with — such as rclone or other file transfer utilities. For consistency, we’ll store the uploaded videos in the COS input bucket using the prefix /videos. Once processed, the upscaled output files will be saved in the COS output bucket, also under the /videos prefix. This structure helps keep your input and output data organized and easy to manage. Become a Medium member\nWith your video files now available in the COS input bucket, the next step is to create a videos.jsonl file. This file serves as a task list for the fleet, where each line contains a JSON object that defines how a specific video should be processed. Each task entry includes the necessary metadata and instructions for handling one video. For example, if you have eight videos to upscale, your videos.jsonl file might look something like this, with one line per video task.\n{ \u0026#34;args\u0026#34;: [\u0026#34;--input\u0026#34;, \u0026#34;/input/video-1.mp4\u0026#34;, \u0026#34;--output\u0026#34;, \u0026#34;/output/video-1-upscale.mp4\u0026#34;, \u0026#34;--processor\u0026#34;, \u0026#34;realesrgan\u0026#34;, \u0026#34;--scaling-factor\u0026#34;, \u0026#34;4\u0026#34;, \u0026#34;--realesrgan-model\u0026#34;,\u0026#34;realesrgan-plus\u0026#34;]} { \u0026#34;args\u0026#34;: [\u0026#34;--input\u0026#34;, \u0026#34;/input/video-2.mp4\u0026#34;, \u0026#34;--output\u0026#34;, \u0026#34;/output/video-2-upscale.mp4\u0026#34;, \u0026#34;--processor\u0026#34;, \u0026#34;realesrgan\u0026#34;, \u0026#34;--scaling-factor\u0026#34;, \u0026#34;4\u0026#34;, \u0026#34;--realesrgan-model\u0026#34;,\u0026#34;realesrgan-plus\u0026#34;]} { \u0026#34;args\u0026#34;: [\u0026#34;--input\u0026#34;, \u0026#34;/input/video-3.mp4\u0026#34;, \u0026#34;--output\u0026#34;, \u0026#34;/output/video-3-upscale.mp4\u0026#34;, \u0026#34;--processor\u0026#34;, \u0026#34;realesrgan\u0026#34;, \u0026#34;--scaling-factor\u0026#34;, \u0026#34;4\u0026#34;, \u0026#34;--realesrgan-model\u0026#34;,\u0026#34;realesrgan-plus\u0026#34;]} { \u0026#34;args\u0026#34;: [\u0026#34;--input\u0026#34;, \u0026#34;/input/video-4.mp4\u0026#34;, \u0026#34;--output\u0026#34;, \u0026#34;/output/video-4-upscale.mp4\u0026#34;, \u0026#34;--processor\u0026#34;, \u0026#34;realesrgan\u0026#34;, \u0026#34;--scaling-factor\u0026#34;, \u0026#34;4\u0026#34;, \u0026#34;--realesrgan-model\u0026#34;,\u0026#34;realesrgan-plus\u0026#34;]} { \u0026#34;args\u0026#34;: [\u0026#34;--input\u0026#34;, \u0026#34;/input/video-5.mp4\u0026#34;, \u0026#34;--output\u0026#34;, \u0026#34;/output/video-5-upscale.mp4\u0026#34;, \u0026#34;--processor\u0026#34;, \u0026#34;realesrgan\u0026#34;, \u0026#34;--scaling-factor\u0026#34;, \u0026#34;4\u0026#34;, \u0026#34;--realesrgan-model\u0026#34;,\u0026#34;realesrgan-plus\u0026#34;]} { \u0026#34;args\u0026#34;: [\u0026#34;--input\u0026#34;, \u0026#34;/input/video-6.mp4\u0026#34;, \u0026#34;--output\u0026#34;, \u0026#34;/output/video-6-upscale.mp4\u0026#34;, \u0026#34;--processor\u0026#34;, \u0026#34;realesrgan\u0026#34;, \u0026#34;--scaling-factor\u0026#34;, \u0026#34;4\u0026#34;, \u0026#34;--realesrgan-model\u0026#34;,\u0026#34;realesrgan-plus\u0026#34;]} { \u0026#34;args\u0026#34;: [\u0026#34;--input\u0026#34;, \u0026#34;/input/video-7.mp4\u0026#34;, \u0026#34;--output\u0026#34;, \u0026#34;/output/video-7-upscale.mp4\u0026#34;, \u0026#34;--processor\u0026#34;, \u0026#34;realesrgan\u0026#34;, \u0026#34;--scaling-factor\u0026#34;, \u0026#34;4\u0026#34;, \u0026#34;--realesrgan-model\u0026#34;,\u0026#34;realesrgan-plus\u0026#34;]} { \u0026#34;args\u0026#34;: [\u0026#34;--input\u0026#34;, \u0026#34;/input/video-8.mp4\u0026#34;, \u0026#34;--output\u0026#34;, \u0026#34;/output/video-8-upscale.mp4\u0026#34;, \u0026#34;--processor\u0026#34;, \u0026#34;realesrgan\u0026#34;, \u0026#34;--scaling-factor\u0026#34;, \u0026#34;4\u0026#34;, \u0026#34;--realesrgan-model\u0026#34;,\u0026#34;realesrgan-plus\u0026#34;]} Explanation of Parameters:\n\u0026ndash;input: Path to the input video file (input bucket mounted from COS) \u0026ndash;output: Path where the upscaled video will be saved (output bucket mounted from COS) \u0026ndash;processor: Specifies the upscaling engine (e.g. realesrgan) \u0026ndash;scaling-factor: Determines the upscale factor (e.g., 2x, 4x) \u0026ndash;realesrgan-model: Chooses the model variant (e.g., realesrgan-plus for live-action content) Dive into the Video2X GitHub repository and its documentation to explore alternative engines and models. This will allow you to fine-tune processing parameters and achieve optimal upscaling results tailored to your specific use case.\nNow that your videos and tasks are prepared, it’s time to launch the fleet using IBM Cloud Code Engine. You can do this via the Code Engine UI or the CLI. In this example, we’ll use the CLI to run the Code Engine Serverless Fleets with the official Video2X container image (ghcr.io/k4yt3x/video2x:6.4.0). The Code Engine Serverless Fleets will be configured to process tasks defined in the videos.jsonl file, with two tasks running in parallel. Of course, this setup is fully customizable—you can scale the number of concurrent tasks, adjust resource allocations, and process as many videos as you upload and define. Each task will be allocated substantial resources \u0026ndash; 20 CPU cores, 100 GB of RAM, and an NVIDIA L40 GPU \u0026ndash; ensuring high-performance video upscaling. Since the maximum scale is set to two, Code Engine will provision two worker VSIs to handle the tasks concurrently, with each worker processing one video at a time. The --tasks-state-store parameter points to a persistent COS bucket used to manage the operational state of the Code Engine Serverless Fleets. Additionally, the --mount-data-store options mount the input and output COS buckets into the container: the input bucket with the prefix /videos is mounted at /input, and the output bucket with the prefix /videos is mounted at the path /output inside the container.\nibmcloud code-engine fleet create --name “upscale-videos” \\ --image \u0026#34;ghcr.io/k4yt3x/video2x:6.4.0\u0026#34; \\ --max-scale 2 \\ --tasks-from-local-file videos.jsonl \\ --gpu l40s \\ --cpu 20 \\ --memory 100G \\ --tasks-state-store fleet-task-store \\ --mount-data-store /input=fleet-input-store:/videos \\ --mount-data-store /output=fleet-output-store:/videos Conclusion # Upscaling videos using IBM Cloud Code Engine Serverless Fleets showcases the power and flexibility of modern serverless architectures for high-performance, GPU-accelerated workloads. By combining the simplicity of Code Engine with the scalability of Serverless Fleets and the efficiency of the Video2X framework, developers can process large volumes of media files in parallel — without the burden of managing infrastructure. This hands-on example demonstrates how easy it is to orchestrate complex tasks like video upscaling in a secure, isolated environment using IBM Cloud Code Engine Serverless Fleets. From provisioning resources with a one-time setup script to defining tasks in a structured videos.jsonl file and executing them with fine-tuned compute configurations, the entire workflow is streamlined for productivity and performance. Whether you\u0026rsquo;re working on media processing, AI inference, or scientific workloads, IBM Cloud Code Engine Serverless Fleets provides a robust and developer-friendly solution. With support for GPU-enabled VSIs, customisable networking, and seamless integration with IBM Cloud Object Storage, you can build scalable, enterprise-grade pipelines with minimal operational overhead. Ready to take it further? Dive into the Video2X GitHub repository to explore various models and fine-tune parameters to suit your needs. Start building your own Code Engine Serverless Fleet powered video processing workflows on IBM Cloud today. While you\u0026rsquo;re at it, be sure to also check out the other powerful components of Code Engine \u0026ndash; Applications, Jobs, and Functions \u0026ndash; as well as additional Serverless Fleets use cases like Batch Inferencing, Docling, and Monte Carlo Simulation available in the sample repository.\n","date":"October 7, 2025","externalUrl":null,"permalink":"/CodeEngine/posts/upscaling-videos-ibm-cloud-code-engine-serverless-fleets/","section":"Posts","summary":"IBM Cloud Code Engine is IBM’s fully managed, strategic serverless platform that empowers developers to run container images, batch jobs, source code, and functions — all in one unified environment. It abstracts away the complexity of infrastructure management, automatically handling scaling, networking, and security so you can focus on building and deploying your applications. With the introduction of Serverless Fleets, IBM Cloud Code Engine now supports large-scale, parallel execution of run-to-completion tasks across multiple virtual machines — securely hosted within your own Virtual Private Cloud (VPC). This gives you the flexibility to define custom subnets and choose from a wide range of Virtual Server Instance (VSI) flavors, including GPU-enabled options, tailored to your workload’s performance needs. What sets Code Engine apart is its serverless nature — it abstracts away the operational complexity of infrastructure management. You don’t need to worry about provisioning, scaling, or securing the underlying compute resources. Instead, you can focus entirely on your application logic and task definitions, while Code Engine handles the orchestration behind the scenes. By running Code Engine Serverless Fleets in a single-tenant environment, you gain enhanced control over performance, security, and compliance. This architecture ensures that your workloads execute in isolated infrastructure, making it ideal for enterprise-grade use cases such as video processing, AI inference, and scientific computing — all with a streamlined developer experience. Check out the introduction to Code Engine Serverless Fleets or look at the documentation.\n","title":"Upscaling Videos with IBM Cloud Code Engine Serverless Fleets","type":"posts"},{"content":"","date":"September 29, 2025","externalUrl":null,"permalink":"/CodeEngine/tags/functions/","section":"Tags","summary":"","title":"Functions","type":"tags"},{"content":"","date":"September 29, 2025","externalUrl":null,"permalink":"/CodeEngine/tags/typescript/","section":"Tags","summary":"","title":"Typescript","type":"tags"},{"content":"LinuxServer.io is a global community of open-source enthusiasts who maintain one of the most extensive collections of standardized Docker images. These images are designed with simplicity, consistency, and transparency in mind — making them ideal for everyone from curious beginners to seasoned self-hosters. Whether you’re looking to run a media server, a productivity tool, or a creative application, LinuxServer.io offers a rich catalog of ready-to-use containers that are well-documented and regularly updated. Just deploy an image, and you can access the application directly in your browser — no complex setup required.\nBut where should you run these powerful, community-maintained applications?\nSimple, IBM Cloud Code Engine! IBM’s fully managed, strategic serverless platform makes deploying and running functions, containers, batch jobs and web apps effortless. With Code Engine, you don’t need to worry about provisioning infrastructure, managing servers, or scaling workloads. It automatically handles all of that for you, allowing applications to scale up when needed and scale down to zero when idle, saving you time, money, and complexity.\nA Match Made in the Cloud # Pairing LinuxServer.io with IBM Cloud Code Engine creates a seamless experience for anyone, be it developers, hobbyists, educators, or even small business owners. Whoever wants to run powerful applications in the cloud without the overhead of traditional infrastructure has come to the right place.\nNo DevOps Required: You don’t need to be a cloud expert to deploy LinuxServer.io containers on Code Engine. Code Engine handles scaling, networking, and resource management automatically. Cost-Efficient: Thanks to Code Engine’s scale-to-zero feature, your applications only consume resources when they’re actively used. Secure and Customizable: Easily add environment variables to configure access controls and personalize your deployments. Flexible Access: Use either the intuitive web UI or the CLI to deploy and manage your applications. Explore the Possibilities # LinuxServer.io offers containers for a wide range of use cases:\nProductivity: LibreOffice, WPS Office, FileZilla… Creativity: Blender, Audacity, kdenlive, gimp… Media \u0026amp; Reading: Jellyfin (Media Server), Calibre (eBook management) … Web Browsing: Chrome, Firefox… Development Tools: Visual Studio Code… Gaming: SteamOS, retroarch, dolphin… You can browse the full catalog of nearly 200 container images here: https://www.linuxserver.io/our-images\nGetting Started with Code Engine # Before deploying your first container, make sure you have the following prerequisites: A activated IBM Cloud Account and a Code Engine Project in your preferred region. If you want to do this in the CLI make sure to install the IBM Cloud CLI and Code Engine Plugin.\nDeploying a LinuxServer.io Container via CLI # Here’s how simple it is to deploy Blender using the Code Engine CLI. Specifly your apps name, the port the image that should be used and as a nice bonus each linuxserver.io image comes with Basic Auth which can be configured using the to environment variables CUSTOM_USER and PASSWORD. This ensures that only you have access to your applications—no complex setup required:\nibmcloud ce app create \\ --name linuxserver-blender \\ --port 3000 \\ --image lscr.io/linuxserver/blender:latest \\ --env CUSTOM_USER=\u0026#34;myuser\u0026#34; \\ --env PASSWORD=\u0026#34;mypwd\u0026#34; Once deployed, Code Engine will provide a secure URL to access your Blender instance. That’s it — your container is live and ready to use!\nDeploying via the IBM Cloud UI # Prefer a visual approach? No problem. Navigate to your Code Engine project : Containers → Serverless Project → your-project → App. Then click the Create button and a creation form for you app will open. Fill in the following values:\nApplication Name Container Image (e.g., lscr.io/linuxserver/chrome:latest) Port (usually 3000 for LinuxServer images) Environment Variables (CUSTOM_USER, PASSWORD) Click Create, and your application will be up and running within minutes. Once deployed, simply grab the URL to access your app directly in your browser — no extra configuration needed. Become a Medium member\nNow that you know how easy it is to deploy containers, feel free to explore and run any other LinuxServer.io image. Just create a new application using the desired image, and you’re good to go!\nExtending Functionality with Persistent Storage # Now that we’ve covered the basics of deploying LinuxServer.io containers on IBM Cloud Code Engine, let’s explore how to add persistent storage using a IBM Cloud Object Storage (COS) bucket — with built-in encryption and multi-region support. This feature is especially useful for applications that need to save files across sessions — like office suites, media editors, or file managers. By mounting a COS bucket directly into your running container, you gain a secure, scalable, and high-performance location to store and retrieve data. To proceed with this section, make sure you’ve completed the optional setup steps: creating a COS bucket and configuring a persistent data store within your Code Engine project.\nTo set up a persistent data storage using IBM Cloud Object Storage (COS) with Code Engine, start by creating a COS instance and bucket, then generate HMAC credentials. See the following documentation for setting up COS. Use these credentials to create a HMAC secret in Code Engine, which you’ll reference when configuring a persistent data store for your COS bucket as described at the followin Code Engine documentation.\nAfter you have created your COS instance, bucket and HMAC credentials you can use the following Code Engine CLI commands to create your secret and persistent data store.\nibmcloud ce secret create \\ --name cos-hmac-secret \\ --access-key-id \u0026lt;your-access-key-id\u0026gt; \\ --secret-access-key \u0026lt;your-secret-access-key\u0026gt; ibmcloud ce pds create \\ --name my-cos-pds \\ --cos-access-secret cos-hmac-secret \\ --cos-bucket-name \u0026lt;your-bucket-name\u0026gt; For example, deploying WPS Office with persistent storage via the CLI is as simple as adding one extra flag:\nibmcloud ce app create \\ --name linuxserver-wps-office \\ --port 3000 \\ --image lscr.io/linuxserver/wps-office:latest \\ --env CUSTOM_USER=\u0026#34;User\u0026#34; \\ --env PASSWORD=\u0026#34;mypwd\u0026#34; \\ --mount-data-store=/mydata=my-cos-pds The --mount-data-store=/mydata=my-cos-pds flag mounts your COS persistent data store (PDS) to the /mydata directory inside the container, allowing WPS Office to read and write files directly to cloud storage.\nUsing the UI, the process is just as straightforward. When deploying an app like LibreOffice, simply specify the persistent data store under the Volume Mounts section in addition to the previously specified configuration. This enables your application to retain documents, configurations, or media files between sessions — perfect for collaborative environments or long-term projects.\nWrapping Up: What’s Next? # You’ve now successfully deployed a variety of LinuxServer.io container images on IBM Cloud Code Engine — all following a simple, standardized process. The only things that typically change are the application name and the container image you choose; everything else remains consistent, making it easy to replicate and deploy new applications.\nAs you explore more applications, consider experimenting with different CPU and memory configurations to optimize performance based on your specific use case. Code Engine also offers advanced features like custom domain mappings, which can help you make your applications more accessible and professional. For added security and flexibility, you can dive into advanced container configurations, or integrate more sophisticated authentication methods to protect your services.\nFinal Thoughts # IBM Cloud Code Engine and LinuxServer.io together provide a powerful, intuitive way to run open-source applications in the cloud. Whether you’re a developer building scalable services, an educator setting up browser-based labs, or a hobbyist exploring creative tools — this combination makes cloud-native computing accessible to everyone.\nReady to get started?\nExplore the LinuxServer.io catalog, pick your favorite app, and deploy it with just a few clicks or a single command directly to IBM Cloud Code Engine. The cloud is yours to build with — simple, secure, and serverless.\n","date":"September 29, 2025","externalUrl":null,"permalink":"/CodeEngine/posts/why-ibm-cloud-code-engine-is-the-perfect-home-for-linuxserverio-application/","section":"Posts","summary":"LinuxServer.io is a global community of open-source enthusiasts who maintain one of the most extensive collections of standardized Docker images. These images are designed with simplicity, consistency, and transparency in mind — making them ideal for everyone from curious beginners to seasoned self-hosters. Whether you’re looking to run a media server, a productivity tool, or a creative application, LinuxServer.io offers a rich catalog of ready-to-use containers that are well-documented and regularly updated. Just deploy an image, and you can access the application directly in your browser — no complex setup required.\n","title":"Why IBM Cloud Code Engine Is the Perfect Home for LinuxServer.io Applications","type":"posts"},{"content":"Have you ever wanted to create a Code Engine Function code bundle that runs as a Python or Node.js function on IBM Cloud Code Engine, without relying on the Code Engine CLI to build it?\nThis guide walks you through a manual method to create a Code Bundle, giving you more control over the build process. While this approach is not encouraged as it can lead to unexplained behaviours it’s ideal for experienced developers who need flexibility in how their functions are packaged and deployed.\nImportant: Ensure you run all commands in an amd64/Linux environment using the correct runtime version for your function. Refer to the Code Engine Function Runtimes documentation for supported versions. You should also have a IBM Cloud account and be familiar with IBM Cloud Code Engine and IBM Cloud Container Registry.\nStep-by-Step Guide # 1. Prepare your source code # You can create either a Python or Node.js function for IBM Cloud Code Engine. Example source code for both runtimes is available in the following GitHub repositories:\nPython code bundle Node.JS code bundle Typically, you would use the Code Engine CLI to build and deploy your function in a single step. For example:\nFor Python: # $ ibmcloud ce fn create -n lorem-python -runtime python-3.11 --build-source . For Node.JS: # $ ibmcloud ce fn create -n lorem-node -runtime nodejs-20 --build-source . After running one of these commands, your function is automatically built, deployed, and ready to invoke via the generated URL — no additional steps required.\nHowever, in this guide, we’ll manually perform the build and packaging steps. This approach gives you deeper insight and greater control over how your function is constructed and deployed.\n2. Installing Dependencies for Your Function # Once you’ve created your source code files __main__.py and requirements.txt for Python, or main.js and package.json for Node.js you can proceed to install any additional dependencies required by your function. Ensure you are in the directory where your source code is.\nFor Python: # Set up a virtual environment and install the dependencies listed in your requirements.txt file. This will create a virtualenv directory containing all the necessary packages:\n$ virtualenv virtualenv $ source virtualenv/bin/activate $ pip install -r requirements.txt For Node.js: # Use npm to install the dependencies defined in your package.json. This will generate a node_modules directory:\n$ npm install These steps ensure that all runtime dependencies are downloaded and ready for packaging into your Code Engine function.\n3. Packaging and Publishing Your Function Code and Dependencies # With your source code and dependencies ready, the next step is to bundle everything into a .tar.gz archive. This archive will later be added to a container image for deployment.\nFor Python: # Include your code __main__.py, dependencies requirements.txt, and the virtual environment directory virtualenv:\n$ tar -czf myfuncbundle.tar.gz __main__.py requirements.txt virtualenv For Node.js: # Include your main.js, package.json, and the node_modules directory:\n$ tar -czf myfuncbundle.tar.gz main.js package.json node_modules Now that your code and dependencies are bundled in a tar.gz , the final step is to create a container image that can be stored in a container registry — specifically, the IBM Cloud Container Registry in this case. This image will contain a single layer with your function. Note that this is not an executable container, it simply holds the function code for Code Engine to extract and run.\nCreate a file named Dockerfile with the following content.\nDockerfile:\nFROM scratch ADD myfuncbundle.tar.gz . Build the image and push it to IBM Cloud Container Registry using the following commands. Replace mynamespace with your actual IBM Cloud Container Registry namespace:\n$ docker build -t us.icr.io/mynamespace/myfuncbundle . $ docker push us.icr.io/mynamespace/myfuncbundle Once pushed, this image can be referenced when creating/updating your function in Code Engine.\n4. Deploying Your Function with a Custom Code Bundle # With your function code bundle pushed to the IBM Cloud Container Registry, you’re ready to create/update your function using the Code Engine CLI. Instead of building from source, you’ll reference your pre-packaged code bundle stored in the registry.\nFor Python: # $ ibmcloud ce function create --name myfunc --runtime python-3.11 --code-bundle us.icr.io/mynamespace/myfuncbundle For Node.JS: # $ ibmcloud ce function create --name myfunc --runtime nodejs-20 --code-bundle us.icr.io/mynamespace/myfuncbundle Be sure to replace mynamespace with your actual IBM Cloud Container Registry namespace.\nThis command creates your function on IBM Cloud Code Engine, using your custom bundle as the source. Once created, the function is ready to be invoked via its generated URL.\nSummary # By manually creating a Code Engine function bundle, you’ve unlocked a deeper understanding of how IBM Cloud Code Engine handles function packaging and deployment. This method gives you full control over your function dependencies and build, process — ideal for advanced use cases or custom CI/CD pipelines. However, for most scenarios, it is strongly recommended to use the Code Engine CLI, which simplifies the process and ensures compatibility with the platform’s evolving features. While the manual approach is powerful, the CLI remains the most reliable and supported way to build and deploy your functions. Happy coding — and may your functions run fast and fault-free!\n","date":"August 4, 2025","externalUrl":null,"permalink":"/CodeEngine/posts/creating-a-ibm-cloud-code-engine-function-code-bundle-from-scratch/","section":"Posts","summary":"Have you ever wanted to create a Code Engine Function code bundle that runs as a Python or Node.js function on IBM Cloud Code Engine, without relying on the Code Engine CLI to build it?\nThis guide walks you through a manual method to create a Code Bundle, giving you more control over the build process. While this approach is not encouraged as it can lead to unexplained behaviours it’s ideal for experienced developers who need flexibility in how their functions are packaged and deployed.\n","title":"Creating a IBM Cloud Code Engine Function Code Bundle FROM scratch","type":"posts"},{"content":"IBM Cloud Code Engine is IBM’s serverless platform that allows developers to run apps, jobs, and functions at scale — without the hassle of managing infrastructure. Among its workload types are functions, which currently support Node.js and Python runtimes. In this post, we’ll explore how to write a TypeScript function and deploy it as a Node.js function on IBM Cloud Code Engine. This approach lets you enjoy the benefits of TypeScript — like static typing and modern language features — while still running your function as JavaScript.\nTypeScript is a superset of JavaScript that adds optional static typing and other powerful features. It helps catch bugs early and improves code maintainability. However, IBM Cloud Code Engine functions expect JavaScript files, so we need to transpile our TypeScript code to JavaScript before deployment.\nLet’s walk through setting up a simple TypeScript-based function that uses a third-party module. The Code can be found in the following GitHub Repository\n1. Create your main function file in TypeScript # Write your function logic in index.ts. For example, the following function imports the lorem-ipsum module and returns a randomly generated paragraph:\nimport { LoremIpsum } from \u0026#34;lorem-ipsum\u0026#34;; interface Params { [key: string]: any; } interface Response { headers: { [key: string]: string }; body: string; } export function main(params?: Params): Response { const lorem = new LoremIpsum(); return { headers: { \u0026#34;Content-Type\u0026#34;: \u0026#34;text/plain;charset=utf-8\u0026#34; }, body: lorem.generateWords(10), }; } 2. Set up your package.json # Define your dependencies and scripts. Include TypeScript as a devDependency, and use the postinstall script to transpile your TypeScript code to JavaScript automatically after installation:\n{ \u0026#34;name\u0026#34;: \u0026#34;ts-func\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;main\u0026#34;: \u0026#34;index.js\u0026#34;, \u0026#34;scripts\u0026#34;: { \u0026#34;postinstall\u0026#34;: \u0026#34;tsc\u0026#34; }, \u0026#34;devDependencies\u0026#34;: { \u0026#34;typescript\u0026#34;: \u0026#34;^5.9.2\u0026#34; }, \u0026#34;dependencies\u0026#34;: { \u0026#34;lorem-ipsum\u0026#34;: \u0026#34;^2.0.8\u0026#34; } } 3. Create a tsconfig.json file # This configuration tells TypeScript how to transpile your code:\n{ \u0026#34;compilerOptions\u0026#34;: { \u0026#34;module\u0026#34;: \u0026#34;nodenext\u0026#34;, \u0026#34;target\u0026#34;: \u0026#34;esnext\u0026#34;, } } 4. Deploy your function to IBM Cloud Code Engine # After setting up all required files (index.ts, package.json, and tsconfig.json), navigate to your project directory and use the IBM Cloud CLI to create or update your function. Since TypeScript is listed as a devDependency and the tsc command is defined in the postinstall script, IBM Cloud Code Engine will automatically run the TypeScript compiler during its build process — saving you the effort of manually transpiling your code.\nibmcloud ce fn create --name ts-func --runtime nodejs-22 --build-source . You’ve now successfully created a Node.js function for IBM Cloud Code Engine — while taking full advantage of TypeScript’s type safety and modern features. Give it a try in your next project and experience the benefits of cleaner, more reliable serverless code.\n","date":"August 4, 2025","externalUrl":null,"permalink":"/CodeEngine/posts/writing-typescript-functions-for-ibm-cloud-code-engien/","section":"Posts","summary":"IBM Cloud Code Engine is IBM’s serverless platform that allows developers to run apps, jobs, and functions at scale — without the hassle of managing infrastructure. Among its workload types are functions, which currently support Node.js and Python runtimes. In this post, we’ll explore how to write a TypeScript function and deploy it as a Node.js function on IBM Cloud Code Engine. This approach lets you enjoy the benefits of TypeScript — like static typing and modern language features — while still running your function as JavaScript.\n","title":"Writing TypeScript Functions for IBM Cloud Code Engine","type":"posts"},{"content":"In this blog post, we’ll explore how you can use IBM Cloud Code Engine to run binaries inside the existing Node.js and Python runtimes.\nIBM Cloud Code Engine is IBMs Strategic serverless compute platform that supports a variety of workloads including functions. A function is a stateless code snippet, that perform tasks as it is invoked by HTTP. For Functions, Code Engine currently supports two programming languages: Node.js and Python. But what if you prefer to use a different language?\nThe solution lies in utilizing one of the existing runtimes, which is provided by IBM Cloud Code Engine. and bundling and executing a binary. In this example, we’ll create a simple function using the Python runtime which will run (subprocess.run), a binary written in Go. We’ll leverage the ability to add the binary to the function’s code bundle during the build process.\nStart by writing a Python function that acts as a wrapper to execute the binary. This wrapper can take the functions parameters and serialize them into a JSON string. The wrapper function will then run the binary, passing the JSON string as a command-line argument. The binary’s output, which will be in JSON format, will be captured and deserialized into a Python dictionary. Finally, this dictionary will be returned as the result of the wrapper function invocation. __main__.py\nimport subprocess import json output_dict={} statusCode = 0 binary=\u0026#34;my-program\u0026#34; def main(params): command = f\u0026#39;./{binary} \\\u0026#39;{json.dumps(params)}\\\u0026#39;\u0026#39; result = subprocess.run(command, shell=True, capture_output=True, text=True) if result.returncode == 0: statusCode = 200 output_dict = json.loads(result.stdout) else: statusCode = 500 output_dict = {\u0026#34;error\u0026#34;:\u0026#34;an error as occured\u0026#34;} return { \u0026#34;headers\u0026#34;: { \u0026#39;Content-Type\u0026#39;: \u0026#39;application/json; charset=utf-8\u0026#39;, }, \u0026#34;statusCode\u0026#34;: statusCode, \u0026#34;body\u0026#34;: output_dict, } Implement the logic of your application in a Go source file (or multiple). The Go binary must be designed to handle input and output in JSON format. In this example, it should receive a JSON object that contains a key, such as “name”, and return a JSON object that includes the provided value along with additional data. This ensures a clear and consistent interface between the wrapper function and the Go binary. It is up to you to add whatever real world functionality you need inside the Go Code. main.go\npackage main import ( \u0026#34;encoding/json\u0026#34; \u0026#34;fmt\u0026#34; \u0026#34;os\u0026#34; ) type Response struct { Key string `json:\u0026#34;key\u0026#34;` Value string `json:\u0026#34;value\u0026#34;` Data interface{} `json:\u0026#34;data\u0026#34;` } func main() { // recive data as json string and unmarshal into variable var inputData map[string]interface{} if len(os.Args) \u0026gt; 1 { jsonString := os.Args[1] err := json.Unmarshal([]byte(jsonString), \u0026amp;inputData) if err != nil { os.Exit(1) } } // Here comes your logic name := \u0026#34;placeholder\u0026#34; if len(inputData) != 0 { name = inputData[\u0026#34;name\u0026#34;].(string) } // return the response json (to the python code) respones := Response{ Key: \u0026#34;New Key\u0026#34;, Value: name, Data: inputData, } responseJSON, err := json.Marshal(respones) if err != nil { os.Exit(1) } fmt.Println(string(responseJSON)) } If deploying this setup from the directory where the Go source code is stored, create a .ceignore file. This file ensures that only the compiled binary, and not the raw Go source code is included in the function code bundle. This step is useful to exclude any unnecessary files. .ceignore\nmain.go Compile your Go source code into a Go binary. Ensure the build is configured for the target architecture and operating system, for Code Engine this is linux/amd64. Proper compilation ensures compatibility and prevents runtime errors. GOOS=linux GOARCH=amd64 go build -o \u0026#34;my-program\u0026#34; -ldflags=\u0026#34;-s -w\u0026#34; ./main.go Your directory should look like this:\n├── __main__.py ├── main.go ├── .ceignore └── my-program Create your code engine function using the IBM Cloud Code Engine CLI Make sure the binary is in the same directory as the Python function code __main__.py. After running the command you will have a code engine function which will execute your go binary as part of the function logic. ibmcloud ce fn create - name \u0026lt;function-name\u0026gt; - runtime python-3.11 - build-source . You can now call your function using the displayed URL And that’s it! You have now successfully created a IBM Code Engine Function by deploying your Python wrapper code and your Go binary and executed it on the IBM Cloud.\n","date":"January 30, 2025","externalUrl":null,"permalink":"/CodeEngine/posts/running-binaries-inside-ibm-cloud-code-engine-function-runtimes/","section":"Posts","summary":"In this blog post, we’ll explore how you can use IBM Cloud Code Engine to run binaries inside the existing Node.js and Python runtimes.\nIBM Cloud Code Engine is IBMs Strategic serverless compute platform that supports a variety of workloads including functions. A function is a stateless code snippet, that perform tasks as it is invoked by HTTP. For Functions, Code Engine currently supports two programming languages: Node.js and Python. But what if you prefer to use a different language?\n","title":"IBM Cloud Code Engine: Running Binaries inside the IBM Cloud Code Engine Function Runtimes","type":"posts"},{"content":" Introduction: # In the dynamic world of cloud computing, efficient deployment pipelines are a crucial part of a seamless development process. IBM Code Engine, a fully managed serverless offering, stands out by simplifying the deployment and running of Applications, Jobs, and Functions in the cloud at scale, eliminating the need for users to manage the underlying infrastructure.\nTo elevate the users development experience and workflow, we\u0026rsquo;ve introduced a dedicated GitHub Action designed to simplify the deployment process for GitHub users leveraging GitHub Actions as their CI/CD pipeline.\nThe GitHub Action ibm/code-engine-github-action empowers Code Engine users to seamlessly build and deploy applications, jobs, and functions directly from their GitHub repositories without the need to first manually build the program that they want to deploy or run multiple cli commands. This integration enhances the overall development lifecycle, providing a streamlined and automated approach to deploying and managing Code Engine resources.\nGetting Started # To get started, ensure that the GitHub Actions feature is enabled for your repository. While GitHub Actions are enabled by default for public repositories, users with private repositories may need to enable it from the Actions tab. All workflow configurations are stored within the .github/workflows directory, making it easily accessible for users to customize and manage their deployment pipelines.\nTo use the ibm/code-engine-github-action GitHub Action you will also need to create an API Key (see the docs) and save it as a secret for your repository (Settings -\u0026gt; Secrets and variables \u0026gt; Actions). In this example the secret is called IBM_IAM_API_KEY.\nAfter you have prepared your repository we can get started with two simple examples: the first on how to deploy a Code Engine App and the second one how to deploy a Code Engine Python Function.\nDeploying an App # Create a directory my-ce-app containing the source code you want to deploy to Code Engine. Inside the my-ce-app directory create the following files which make up a simple NodeJS Web Server.\napp.js\nconst express = require(\u0026#34;express\u0026#34;); const app = express(); const port = 8080; app.use(express.urlencoded({ extended: true })); app.use(express.json()); app.get(\u0026#34;/\u0026#34;, (req, res) =\u0026gt; { res.setHeader(\u0026#34;Content-Type\u0026#34;, \u0026#34;application/json\u0026#34;); res.status(200).send(JSON.stringify({ body: \u0026#34;Hello from Node\u0026#34; })); }); const server = app.listen(port, () =\u0026gt; { console.log(`Example app listening at http://localhost:${port}`); }); process.on(\u0026#34;SIGTERM\u0026#34;, () =\u0026gt; { console.info(\u0026#34;SIGTERM signal received.\u0026#34;); server.close(() =\u0026gt; { console.log(\u0026#34;Http server closed.\u0026#34;); }); }); package.json\n{ \u0026#34;dependencies\u0026#34;: { \u0026#34;express\u0026#34;: \u0026#34;^4.17.1\u0026#34; } } Next, inside of the .github/workflows create the following GitHub Action workflow YAML called deploy-ce-app.yml. The workflow called Deploy App to Code Engine is executed when a push occurs against the main branch of the repository. Initially it checks out the repository. In the next step, the ibm/code-engine-github-action will be used to deploy the application (component: app) to Code Engine. It uses Code Engine\u0026rsquo;s push feature so we don\u0026rsquo;t need to create the container image ourselves. The deployment will be directed to the project MY-PROJECT within your default resource group in the Frankfurt region (eu-de). The application will be named my-ce-node-app, utilizing the content of the my-ce-app directory as the source code used for the build step. For more information about Code Engine Push see the Code Engine Build Docs.\ndeploy-ce-app.yml\nname: Deploy App to Code Engine on: push: branches: - main jobs: app: runs-on: ubuntu-latest steps: - name: Check out code uses: actions/checkout@v3 - name: Deploy Application to Code Engine uses: ibm/code-engine-github-action@v1 with: api-key: ${{ secrets.IBM_IAM_API_KEY }} region: \u0026#39;eu-de\u0026#39; project: \u0026#39;MY-PROJECT\u0026#39; component: \u0026#39;app\u0026#39; name: \u0026#39;my-ce-app\u0026#39; build-source: \u0026#39;./my-ce-app\u0026#39; Now, whenever changes are pushed into the main branch the Github Action is run and your Code is built and deployed to Code Engine always keeping your Application up to date with your latest changes.\nDeploying a Python Function # Create a directory my-ce-py-func containing your function source code you want to deploy to Code Engine. Inside the my-ce-py-func directory create the following files which make up a simple python function.\nmain.py\nfrom lorem_text import lorem def main(params): words = 10 return { \u0026#34;headers\u0026#34;: { \u0026#34;Content-Type\u0026#34;: \u0026#34;text/plain;charset=utf-8\u0026#34;, }, \u0026#34;body\u0026#34;: lorem.words(words), } requirements.txt\nlorem-text Like the Application example inside of the .github/workflows create the following GitHub action Workflow YAML called deploy-ce-py-func.yml The workflow called Deploy Python Function to Code Engine is executed when a push occurs against the main branch of the repository. The ibm/code-engine-github-action will be used to deploy the Python Function (component: fn) to Code Engine. The deployment will be directed to the project MY-PROJECT within your default resource group in the Frankfurt region (eu-de). The Function will be named my-ce-py-fn, utilizing the content of the my-ce-py-func directory as the source code.\ndeploy-ce-py-func.yml\nname: Deploy Python Function to Code Engine on: push: branches: - main jobs: fn-py: runs-on: ubuntu-latest steps: - name: Check out code uses: actions/checkout@v3 - name: Deploy Python Function to Code Engine uses: ibm/code-engine-github-action@v1 with: api-key: ${{ secrets.IBM_IAM_API_KEY }} region: \u0026#39;eu-de\u0026#39; project: \u0026#39;MY-PROJECT\u0026#39; component: \u0026#39;fn\u0026#39; runtime: python-3.11 name: \u0026#39;my-ce-py-fn\u0026#39; build-source: \u0026#39;./my-ce-py-func\u0026#39; Conclusion # In this blog, we learned how to create Applications and Functions and automatically deploy them to [IBM Cloud Code Engine] using GitHub Actions as a CI/CD solution. The Code Engine enables developers to effortlessly enhance their development workflows by leveraging a fully managed serverless solution. The workflows depicted above powered by ibm/codeengine-github-action simplify and enhance your deployment process and experience.\nNow its up to you! To get started, head on over to IBM Cloud Code Engine and register for a new account or login to an existing IBM Cloud account and begin your serverless journey with Code Engine. Run your Applications, Jobs or Functions in the Cloud at scale. The documentation, additional information and examples can be found at the included links.\nCode Engine Code Engine Docs Example Code Code Engine Github Action Example Source Code ","date":"February 23, 2024","externalUrl":null,"permalink":"/CodeEngine/posts/deploying-apps-jobs-and-functions-using-github-actions/","section":"Posts","summary":"Introduction: # In the dynamic world of cloud computing, efficient deployment pipelines are a crucial part of a seamless development process. IBM Code Engine, a fully managed serverless offering, stands out by simplifying the deployment and running of Applications, Jobs, and Functions in the cloud at scale, eliminating the need for users to manage the underlying infrastructure.\nTo elevate the users development experience and workflow, we’ve introduced a dedicated GitHub Action designed to simplify the deployment process for GitHub users leveraging GitHub Actions as their CI/CD pipeline.\n","title":"IBM Cloud Code Engine: Deploying Apps, Jobs and Functions using GitHub Actions","type":"posts"},{"content":"","externalUrl":null,"permalink":"/CodeEngine/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"}]